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Foreword 

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical 
Commission) form the specialized system for worldwide standardization. National bodies that are members of 
ISO or IEC participate in the development of International Standards through technical committees 
established by the respective organization to deal with particular fields of technical activity. ISO and IEC 
technical committees collaborate in fields of mutual interest. Other international organizations, governmental 
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information 
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1 . 

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. 

The main task of the joint technical committee is to prepare International Standards. Draft International 
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as 
an International Standard requires approval by at least 75 % of the national bodies casting a vote. 

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent 
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. 

ISO/IEC 21000-5 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information Technology, 
Subcommittee SC 29, Coding of Audio, Picture, and Multimedia and Hypermedia Information. 

ISO/IEC 21000 consists of the following parts, under the general title Information Technology — Multimedia 
Framework. 

— Part 1: Vision, Technologies, and Strategy 

— Part 2: Digital Item Declaration 

— Part 3: Digital Item Identification 

— Part 4: Intellectual Property Management and Protection 

— Part 5: Rights Expression Language 

— Part 6: Rights Data Dictionary 

— Part 7: Digital Item Adaptation 

— Part 8: Reference Software 

— Part 9: File Format 

— Part 1 0: Digital Item Processing 

— Part 1 1 : Persistent Association 

— Part 12: Test Bed for MPEG-21 Resource Delivery 
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Introduction 

The growth of the Internet has enabled worldwide distribution and consumption of valuable multimedia 
resources, reduced the cost of doing business, enabled new business models for industry participants, and 
provided consumers with unprecedented access to high-quality multimedia resources. Internal distribution, 
external distribution, and retail sales now are conducted on the Internet to establish cost effective, reliable, 
flexible, highly available, and secure means of managing the delivery of multimedia resources. Consumers 
routinely search for and download multimedia resources from sources world-wide and can conveniently 
redistribute those resources. This has fuelled the development of technologies to manage, secure, control, 
and automate the flow of multimedia resources over the Internet. 

The free and convenient flow of multimedia resources through the Internet presents many challenges to 
content owners and distributors. Before making high-quality and valuable multimedia resources available 
online, content owners want to be assured that their rights to those resources are respected. In addition, the 
business models and contracts of content distributors often involve conditions regarding distribution, such as 
fees, territory restrictions, time limits, and so on. 

To meet these requirements, the players involved in the online distribution and consumption of multimedia 
resources need to exchange information about the rights, terms, and conditions associated with each 
resource at each step in the multimedia resource lifecycle. For example, a publisher needs to communicate 
the available consumption rights and the terms and conditions under which those rights may be exercised. To 
use the multimedia resources, a consumer needs to know the types of usage allowed and the terms and 
conditions that must be met. In distribution and super distribution business models, this information needs to 
be communicated to each participant in the distribution chain. 

Depending on the business model, expressing rights, terms, and conditions can be simple or complex. In a 
simple example, a consumer might pay a flat fee to obtain unlimited rights to play a video file. In a more 
complex example, a video publisher might grant a distributor the right to sell usage rights for classic movie 
titles to consumers. The distribution agreement might specify the rights that consumers may purchase, the 
maximum fee the distributor may charge, and a percentage of the fee that must be paid to the publisher. 

In an end-to-end system, other considerations such as authenticity and integrity of Rights Expressions 
become important. For example, any party who issues rights to use or distribute multimedia resources must 
be identified and authorized. In addition, a Rights Expression may be accessed by different participants 
during its life cycle, which requires mechanisms and semantics for validating the authenticity and integrity of 
the Rights Expression. 

To address many of these issues, a common Rights Expression Language that can be shared among all 
participants in this digital workflow is required. A common Rights Expression Language addresses important 
aspects of the interoperability issues inherent in digital multimedia resource distribution; the issues relating to 
exchanging Rights Expressions during their life cycle; and the system issues such as trust, authorization, and 
authentication. 

This part of ISO/IEC 21000 addresses a part of the overall vision for ISO/IEC 21000, which is to define a 
multimedia framework to enable transparent and augmented use of multimedia resources across a wide range 
of networks and devices used by different communities. 
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Information Technology — Multimedia Framework — Part 5: 
Rights Expression Language 



1 Scope 

This part of ISO/IEC 21000 specifies the syntax and semantics of a Rights Expression Language. 

This part of ISO/IEC 21000 does not give any permission, including permissions about who is legally or 
technically allowed to create Rights Expressions. It does not specify the security measures of trusted systems, 
propose specific applications, or describe the details of the systems required for accounting (monetary 
transactions, state transactions, and so on). It also does not specify if or when Rights Expressions shall be 
consulted. 

However, this part of ISO/IEC 21000 does define an authorization model to specify whether the semantics of a 
set of Rights Expressions permit a given Principal to perform a given Right upon a given optional Resource 
during a given time interval based on a given authorization context and a given trust root. 

Clause 1 gives the scope of this part of ISO/IEC 21000. Clause 2 gives the normative references. Clause 3 
gives pertinent terms, definitions, symbols, and abbreviated terms. Clause 4 gives the namespaces and 
conventions. Clause 5 specifies the authorization model. Clause 6 defines architectural concepts. Clause 7 
specifies the syntax and semantics integral to the architecture. Clause 8 specifies syntax and semantics 
peripheral to the architecture but still useful in many domains beyond multimedia. Clause 9 specifies syntax 
and semantics specific to multimedia. Annex A uses W3C XML Schema to normatively specify the syntax of 
the types and elements defined throughout this part of ISO/IEC 21000. Annex B normatively defines Qualified 
Names for identifying countries, regions, and currencies. Annex C gives an informative simplified equality 
algorithm. Annex D gives some example Rights Expressions. Annex E describes the design philosophy for 
extensions and profiles of this part of ISO/IEC 21000. Annex F demonstrates how to introduce new rights as 
an extension to this part of ISO/IEC 21000. Annex G gives an example profile of this part of ISO/IEC 21000. 
Annex H describes the relationship between ISO/IEC 21000-6 and this part of ISO/IEC 21000. Annex I 
describes the relationship between ISO/IEC 21000-2 and this part of ISO/IEC 21000. Annex J describes an 
example revocation mechanism and gives a walk-through of revocation. 



2 Normative references 
2.1 General 

The following referenced documents are indispensable for the application of this document. For dated 
references, only the edition cited applies. For undated references, the latest edition of the referenced 
document (including any amendments) applies. 

ISO 3166 (all parts), Codes for the representation of names of countries and their subdivisions 
ISO 4217 (all parts), Codes for the representation of currencies and funds 

ISO/IEC 9594-8, Information Technology — Open Systems Interconnection — The Directory: Public-key and 
attribute certificate frameworks 

ISO/IEC 10021-2, Information Technology — Message Handling Systems (MHS): Overall architecture 
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ISO/IEC 21000 (all parts), information Technoiogy — Multimedia Framework 

Request for Comments (RFC) 1034, Domain Names - Concepts and Facilities, The Internet Engineering Task 
Force (IETF), November 1987, available at <http://www.ietf.org/rfc/rfc1034> 

RFC 1738, Uniform Resource Locators (URL), IETF, December 1994, available at 
<http://www.ietf.org/rfc/rfc1 738.txt> 

RFC 2141, URN Syntax, IETF, May 1997, available at <http://www.ietf.org/rfc/rfc2141.txt> 

RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, IETF, August 1998, available at 
<http://www.ietf.org/rfc/rfc2396.txt> 

RFC 2822, Internet Message Format, IETF, April 2001 , available at <http://www.ietf.org/rfc/rfc2822> 

ROUTINGABA, Routing Number Policy, American Bankers Association Routing Number Administrative Board, 
November 1996, available at <http://www.tfp.comAexVaba_policy.pdf> 

SCC14N, Schema Centric XML Canonicalization Version 1.0, Organization for the Advancement of Structured 
Information Standards (OASIS) Universal Description, Discovery, and Integration (UDDI) Technical 
Committee (TC) Committee Specification, 19 July 2002, available at 
<http://www.uddi.org/pubs/SchemaCentricCanonicalization-20020710.htm> 

UDDIV2API, UDDI Version 2.04 API Specification, OASIS Standard, 19 July 2002, available at 
<http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm> 

UDDIV2DSR, UDDI Version 2.03 Data Structure Reference, OASIS Standard, 19 July 2002, available at 
<http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm> 

UDDIV3, UDDI Version 3.0, OASIS UDDI TC Committee Specification, 19 July 2002, available at 
<http://uddi.org/pubs/uddi-v3.00-published-20020719.htm> 

WSDLSPEC, Web Services Description Language (WSDL) 1.1, Worldwide Web Consortium (W3C) Note, 15 
March 2001 , available at <http7/www.w3.org/TR/2001 /NOTE-wsdl-2001 031 5> 

XMLSPEC, Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, 6 October 
2002, available at <http://www.w3.org/TR/2000/REC-xml-20001006> 

XMLDSIG, XML-Signature Syntax and Processing, W3C Recommendation, 12 February 2002, available at 
<http://www.w3.org/TR/2002/REC-xmldsig-core-2002021 2> 

XMLENC, XML-Encryption Syntax and Processing, W3C Recommendation, 10 December 2002, available at 
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021 21 0> 

XMLINFOSET, XML Information Set, W3C Recommendation, 24 October 2001, available at 
<http://www.w3.org/TR/2001/REC-xml-infoset-2001 1 024> 

XMLNAMES, Namespaces in XML, W3C Recommendation, 14 January 1999, available at 
<http://www.w3.0rg/TR/1 999/REC-xml-names-1 99901 1 4> 

XMLSCHEMA, XML Schema Part 1: Structures and Part 2: Datatypes, W3C Recommendation, 2 May 2001, 
available at <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502> and 

<http://www.w3.org/TR/2001/REC-xmlschema-2-2001 0502> 

XPATH, XML Path Language (XPath) Version 1.0, W3C Recommendation, 16 November 1999, available at 
<http://www.w3.orgyTR/1 999/REC-xpath-1 9991 1 1 6> 
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2.2 Referenced specifications 

All references in this subclause were correct at the time of approval of this part of ISO/IEC 21000. The 
provisions of the referenced specifications, as identified in this subclause, are valid within the context of this 
part of ISO/IEC 21000. The reference to a specification within this part of ISO/IEC 21000 does not give it any 
further status within ISO/IEC; in particular, it does not give the referenced specification the status of an 
International Standard. 

RFC 1034 

RFC 1738 

RFC 2141 

RFC 2396 

RFC 2822 

ROUTINGABA 

SCC14N 

UDDIV2API 

UDDIV2DSR 

UDDIV3 

WSDLSPEC 

XMLSPEC 

XMLDSIG 

XMLENC 

XMLINFOSET 

XMLNAMES 

XMLSCHEMA 

XPATH 

3 Terms, definitions, symbols, and abbreviated terms 

For the purposes of this document, the following terms, definitions, symbols, and abbreviated terms apply. 
3.1 

Allowable Destination Condition 

allowable destination condition as mentioned in 7.4.7 

3.2 

Allowable Destination Delegation Control 

allowable destination delegation control as mentioned in 7.4.7 



© ISO/IEC 2003 



— All rights reserved 



3 



ISO/IEC FDIS 21000-5:2003(E 



3.3 

Allowable Destination Principal 

allowable destination principal as mentioned in 7.4.7 

3.4 

authorization context 

set of properties having the characteristics defined in 5.3 
3.5 

Authorization Context Member 

fifth member 

NOTE This term is used with respect to an authorization request, as in "the Authorization Context Member of the 
authorization request." 

3.6 

authorization proof 

authorization story having the characteristics defined in 5.7 
3.7 

authorization request 

ordered seven-tuple as defined in 5.2 

3.8 

authorization story 

ordered triple as defined in 5.4 

3.9 

authorizer 

ordered five-tuple as defined in 5.5 
3.10 

Business Service 

businessService as defined in UDDIV2DSR and UDDIV3 
3.11 

conceptually abstract 

designated as being subject to the provisions given in 6.6 
3.12 

Condition 

permission limitation identified by an r : Condition 
NOTE See 4.3 for the meaning of r : Condition. 
3.13 

Conditionally 

in a manner subject to a Condition 
3.14 

Core Namespace 

Namespace for the names defined in Clauses 5, 6, and 7 

3.15 
Derived 

derived as defined in 6.9.1 
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3.16 
Equal 

equal as defined in 6.1 

3.17 
License 

Spr^S^te created by Principals to Conditionally or Unconditionally permit the same or other Principals 
to perform Rights upon Resources 

3.18 
Match 

match as mentioned in 7.4.6.1 
3.19 

Multimedia Extension Namespace 

Namespace for the names defined in Clause 9 

3.20 

Namespace 

XML namespace as defined in XMLNAMES 
3.21 

performance 

carrying out or execution 

3.22 

primitive grant 

r: Grant that has no child r:forAll element 
3.23 

Principal 

system entity identified by an r: Principal 

NOTE 1 See 4.3 for the meaning of r : Principal. 

NOTE 2 Many Users (as introduced in ISO/IEC 21000-1) are Principals. 

3.24 

Qualified Name 

qualified name as defined in XMLNAMES 
3.25 

Un^ersal Description, Discovery, and Integration registry as defined in UDDIV2API and UDDIV3 
3.26 

repository 

Principal that can hold Resources 

EXAMPLE Personal systems, on-line storefronts, libraries, and archives are examples of repositories. 
3.27 

Resource 

entity, quality, event, state, concept, substance, or anything else referred to by a noun and identified by an 
r : Resource 

NOTE 1 See 4.3 for the meaning of r : Resource. 
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NOTE 2 ISO/IEC 21000-2 defines resource in a narrower sense than Resource is defined here. The relation might be 
characterized by the expression "a resource is a Resource that is also an asset." 

3.28 

resource attribute set definition element 

element that is one of those defined in 9.3 

3.29 

Resource Member 

third member 

NOTE This term is used with respect to an authorization request, as in "the Resource Member of the authorization 
request." 

3.30 

revocable 

ordered pair as defined in 6.7 

3.31 
Right 

act identified by an r : Right 

NOTE See 4.3 for the meaning of r : Right. 

3.32 

Right Member 

second member 

NOTE This term is used with respect to an authorization request, as in "the Right Member of the authorization 
request." 

3.33 

Satisfied 

satisfied as mentioned in 7.4.5 
3.34 

Standard Extension Namespace 

Namespace for the names defined in Clause 8 

3.35 

Surpasses 

surpasses as defined in 6.8.1 

3.36 
service 

system entity that provides functionality 

NOTE 1 There is no requirement that a service be located on a physically different machine than a client. 

NOTE 2 There is no requirement that a service be part of a different executable than a client. 

3.37 

system entity 

entity that is capable of acting in a system 

EXAMPLE An automated process, a subsystem, and a person or group of persons are examples of system entities. 
3.38 

Trust Root Member 

seventh member 
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NOTE This term is used with respect to an authorization request, as in "the Trust Root Member of the authorization 
request." 

3.39 

Unconditionally 

in a manner not subject to any Condition 

3.40 
URI 

Uniform Resource Identifier [RFC 2396] 
3.41 

Variable 

variable as defined in 6.5.1.1 

3.42 
WSDL 

Web Services Description Language [WSDLSPEC] 

3.43 
XML 

Extensible Markup Language [XMLSPEC] 

3.44 
XPath 

XML Path Language [XPATH] 
3.45 

the r: issue element 

3.46 

P 

the r rpossessProperty element 

4 Namespaces and conventions 

4.1 Namespaces 

The Core Namespace shall be urn:mpeg:mpeg2i:2003:Ol-REL-R-NS. The Standard Extension 
Namespace shall be urn:mpeg:mpeg2i:2003:0i-REL-sx-NS. The Multimedia Extension Namespace 
shall be urn:mpeg:mpeg2i:2003:0i-REL-MX-NS. In each of these, the 01 represents a serial number 
that is expected to change as this part of ISO/IEC 21000 evolves. 

4.2 Namespace conventions 

Throughout this part of ISO/IEC 21000, Qualified Names are written with a namespace prefix followed by a 
colon followed by the local part of the Qualified Name as shown in the following example. 

EXAMPLE r: grant 

For clarity, throughout this part of ISO/IEC 21000, consistent namespace prefixes are used. Table 1 gives 
these prefixes and the corresponding namespace. Licenses compliant with this part of ISO/IEC 21000 are not 
limited to the namespace prefixes in Table 1 for the corresponding namespace and may use any appropriate 
namespace prefix that is declared in the License. 
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Table 1 — Namespace prefixes 



Namespace prefix 


Namespace 


r 


urn :mpeg;mpeg21 : 2003 ; 01-REL-R-NS 


sx 


urn :mpeg :mpeg21 : 2003 : 01-REL-SX-NS 


mx 


urn rmpeg :mpeg21 : 2003 : 01-REL-MX-NS 


dsig 


http; //www. w3 .org/2000/09/xmlds±g# 


xenc 


ht t p : / /www . w3 . org /2001/04 /xmlenc # 


xsd 


http://www.w3.org/2001/XMLSchema 


xsi 


http: //www.w3 . org/ 2 00 1/XMLScheraa- instance 


didl 


urn :mpeg:mpeg21 : 2002 : 01 -DIDL- NS 


dii 


urn rmpeg :mpeg21 : 2002 : 01-DII-NS 


wsdl 


http: //schema s .xmlsoap.org/wsdl/ 


soap 


http: // schema s .xmlsoap.org/wsdl/soap/ 


acme 


This namespace prefix is used for demonstration only. 



4.3 Special typographical conventions 

Fixed-width font is used to indicate literal machine-readable character sequences. 

The names of XML Schema elements and attributes appear in fixed-width font in mixed case with an initial 
lower case letter. The names of XML Schema types appear in fixed-width font in mixed case with an initial 
upper case letter. 

Specific linguistic constructions are used in this part of ISO/IEC 21000 with respect to these conventions in 
order to more concisely convey the intention. They are as follows: 

— A passage that mentions an element, as in "the r: grant," is using the word in a technical sense to refer 
to the notion of that element as an XML Schema element. 

— A passage that mentions a type and prefixes the type with the word type, as in "the type r: Grant," is 
using the word in a technical sense to refer to the notion of that type as an XML Schema type. 

— A passage that mentions a type and prefixes the type with an article, such as a or the, as in "an 
r : Grant," is using the word in a technical sense to refer to any element whose type is that type or any 
derivation thereof (or, in the case of a simple type, any simple content whose type is that simple type or 
any derivation thereof). Semantics assigned to a type in this way shall not be overridden by type 
derivations or elements using the type; type derivations or elements that use the type may alter the 
semantics only as long as all the statements made about the type in these passages still hold for the type 
derivations and elements that use the type. 

4.4 XML structural notation conventions 

To refer to child elements of an element represented by a variable, the variable name is followed by a forward 
slash and the name of the particle against which the child elements validate as shown in Example 1. 

EXAMPLE 1 Suppose g is the following r : grant: 
<r: grant > 

<r:keyHolder> . . . </r :keyHolder> 

< acme : extensionRight / > 

<r:keyHolder>. . . </r :keyHolder> 
< /r: grant > 
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In this case, g/r : principal would refer to the first r rkeyHolder child because it validates against the r principal 
particle, which comes before the r: right particle in an r: grant. The second r:keyHoider validates against the 
r : resource particle, which comes after the r : right in an r : grant. 

NOTE For more details about the syntax of r : grant, see Annex A. 

To refer to child elements of child elements of an element represented by a variable, another forward slash is 
used as shown in Example 2. 

EXAMPLE 2 c/sx : locat ion/sx : country 

To refer to attributes of an element represented by a variable, the variable name is followed by a forward slash, 
an at sign (@), and then the name of the attribute as shown in Example 3. 

EXAMPLE 3 //@r : licenseld 

To avoid confusion with XPath notation, when XPath notation is used in this part of ISO/IEC 21000, its use is 
clearly indicated with wording such as "the following XPath location path." 

4.5 Authorization context conventions 

To refer to the value of a property of an authorization context variable, the variable name is followed by a full 
stop followed by the property name as shown in Example 1 and Example 2. 

EXAMPLE 1 Xacme:a1 0 refers to the value of the acme:a1 property of the authorization context X 

EXAMPLE 2 If the value of jc is 123, then 2-.acme:a2(x) refers to the value of the acme:a2(123) property of the 
authorization context S. 

NOTE For more details about authorization contexts, see 5.3. 



5 Authorization model 
5.1 General 

This Clause specifies the authorization model. 

NOTE The authorization model makes use of an authorization request, an authorization context, an authorization 
story and an authorizes These are used to create authorization proofs which help to define the semantics of Licenses 
with respect to authorization requests. Figure 1 illustrates the relationship between the components of the authonzation 
model. 
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Authorization story 



Primitive grant 



Authorized r : Grant or r : GrantGroup 



Authorizer 



r : License 



r: Principal 



Time instant 



Authorization context 



Authorization story 



is authorization 
proof for 



Authorization request 



r : Principal 



r: Right 



r : Resource 



Interval of time 



Authorization context 



r : License elements 



r : Grant elements that 
do not require an 
authorizer 



Figure 1 — Authorization Model 

5.2 Authorization request 

An authorization request is an ordered seven-tuple containing the following members, in order: 

a) optionally, the r : Principal identifying the Principal for which permission is requested, 

b) the r: Right identifying the Right the performance of which is requested to be permitted, 

c) optionally, the r : Resource identifying the Resource upon which permission is requested, 

d) the interval of time in which the requested performance of b) by a) upon c) is to occur, 

e) the authorization context containing properties representing statements that are to be considered true for 
the purposes of establishing the requested permission, 

f) the set of r: License elements that may be consulted to establish the requested permission, and 

g) the set of r: Grant elements that do not require an authorizer for the purposes of establishing the 
requested permission. 

NOTE 1 An authorization request can be conceptualized as representing the question "is it permitted for a given 
Principal to perform a given Right upon a given Resource during a given time interval based on a given authorization 
context, a given set of Licenses, and a given trust root?" 



Each of the r : License elements / in the set mentioned in f) shall have exactly one //r : issuer child. 
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NOTE 2 The semantics of an r: License / with a different number of //r : issuer children is specified in terms of 
r : License elements with one such child each (see 6.4 for the specifics). 



5.3 Authorization context 

An authorization context is a set of properties having the following characteristics: 

— each property consists of exactly one name and one value, 

— a property name consists of exactly one Qualified Name and zero or more parameters, 

— no two properties in an authorization context share the same property name, and 



— each property represents a statement. 

NOTE 5.6, 7.2, 8.2, and 9.2 define authorization context properties and the statements they represent. 



5.4 Authorization story 

An authorization story is an ordered triple containing the following members, in order: 



a) a primitive grant, 

b) either an r : Grant or an r : GrantGroup, and 

c) optionally, an authorizes 

NOTE Conceptually, the first member of an authorization story is used to demonstrate to which authorization 
requests the authorization story applies. The second member of an authorization story represents the actual r: Grant or 
r : GrantGroup that is authorized by the third member of the authorization story. 



5.5 Authorizer 

An authorizer is an ordered five-tuple containing the following members, in order: 



a) an r : License, 



b) an r : Principal, 

c) a time instant, 

d) an authorization context, and 

e) an authorization story. 

NOTE Conceptually, if an r : Grant or r: GrantGroup is authorized, it is part of a License and is authorized in that 
License by some Principal at some time instant based on some authorization context and there is an authorization story 
explaining why that Principal was permitted to make that authorization. 



5.6 Authorization model authorization context properties 

Table 2 specifies the authorization context properties relating specifically to the authorization model and the 
statements they represent. If a property has the name given in the first column of Table 2 and the value given 
in the second column of Table 2, then the statement represented by that property is the statement given in the 
third column of Table 2. 
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Table 2 — Authorization model authorization context properties 



Property name 



Property value 



Statement represented 



r:issueTime{/, p) 



i 



I is an r : License, p is an r: Principal, z is a time instant, and p 
issued / at i. 



NOTE 1 The r : timeOf issue field in an r: issuerDetails 
(see 7.3.1.6.3) can be useful in determining when p issued /. 
However, it is wise to give consideration as to whether the issuer is 
trustworthy and, when in doubt, to seek additional proof, such as in 
the form of signatures and countersignatures. 



NOTE 2 The r : issuer can be useful in determining whether p 
issued /. However, it is wise to give consideration as to whether the 
information given in the r: Issuer is trustworthy and, when in 
doubt, to seek additional proof, such as in the form of signatures 
and countersignatures. 



r:issueContext(/,/>, h, 2) 



true 



/ is an r: License, p is an r: Principal, h is either an r: Grant 
or an r: Grant Group, Z is an authorization context, and the 
statements represented by the properties in z are all true for the 
purposes of establishing the permission for the Principal identified 
by p to include an r : Grant or r : Gran t Group that is Equal to h as 
//r: grant or //r : grantGroup when issuing /. 



5.7 Authorization proof 

A finite authorization story (g, h t e) is said to be an authorization proof for an authorization request (p, r, /, v f 2", 
L, R) if and only if all of the following are true: 

— either p Surpasses g/r i principal or g/r : principal is absent, 

— g/r : right is Equal to r f 

— either g/r i resource is Equal to * or both are absent, 

— either g/r: condition is Satisfied with respect to authorization request (p, r, t, v, X, L, R) and 
authorization story (g 9 h, e) or g/r : condition is absent, 

— g is Derived from h with respect to authorization request (p, r, t 9 v,Z,L, R) and authorizer e, 

— if e is absent, then h is a member of R, and 

— if e is present, then, letting (/, jt, i, a, s) be the ordered five-tuple representation of e, all of the following are 
true: 

— / is a member of L, 

— h is Equal to one of the //r : Grant or l/r : GrantGroup children of /, 

— x.r:issueTime(/, ji) is i, 

— Xr:issueContext(/, ar, h t o) is true, 

— the time instant i is no later in time than the start of time interval v, and 
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— s is an authorization proof for the authorization request fa, I,h,y t a, L, R) where y> is a time interval 
of zero length starting at L 

5.8 License Semantics 

If there is an authorization proof for an authorization request (p, r, *, v, S, L, R), then the semantics of the set of 
r: License elements L with respect to that authorization request is that they permit the optional Principal 
identified by p to perform the Right identified by r over the optional Resource identified by t during the time 
interval v based on the authorization context z and the set R of r : Grant elements that do not require an 
authorizer. 



6 Architectural concepts 

6.1 Equality 

Let a and b be XML elements. Let a and p be the result of the execution of the Schema Centric 
Canonicalization algorithm (see SCC14N) on an XML Information Set (see XMLINFOSET) whose document 
information item contains in its [children] property the item a or b, respectively. Then a is Equal to b if and only 
if the bits strings a and p are bit-for-bit identical. 

NOTE Annex C presents an approach to efficiently testing for equality. 

6.2 License syntax 

Licenses shall be valid r : License elements. 

6.3 License parts 

The following provisions apply to r: License elements that contain r :LicensePart elements having the 
r: licensePartld or r: licensePartidRef attributes. 

a) An r:LicensePart shall not have both the r: licensePartld attribute and the 
r:licensePartldRef attribute. 

b) For a given r:LicensePartid value v and r: License /, / shall not contain more than one 
r :LicensePart having an r : licensePartld attribute with the value v. 

c) If an rrLicensePart has an r:licensePartidRef attribute, then it shall have empty content. As a 
corollary, types that are derivations of the type r:LicensePart should allow their content to be empty 
(for otherwise their r: licensePartidRef attribute shall not be used). 

d) If an r:LicensePart a has an r: licensePartidRef attribute with a certain value v, then there shall 
exist some (other) rrLicensePart b in the same r: License as a such that all of the following are true: 

1) b has an r : licensePartld attribute with value v, 

2) the expanded element name of b exactly matches that of a, and 

3) b is not an ancestor of a. 

e) With the exception of signature verification and License issuer resolution (see 6.4), the following two 
processing steps shall be carried out before the other License processing steps defined in this part of 
ISO/IEC 21000. In particular, they shall be carried out before the evaluation of Variable references or the 
testing of equality. 
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1) If an r:LicensePart a has an r: licensePartidRef attribute with a certain value v, and b is the 
r:LicensePart in the same nLicense as a that has an r: licensePart id attribute with value 
v, then the semantics of the r : License containing a and b are as if 

i) a were removed from the r : License and replaced with an element a that is Equal to b, 

ii) the r : licensePart id attributes were removed from a and all of its descendants, and 

iii) any preserved attributes that a has were removed from a, and any preserved attributes that a 
has were added to a, where here a preserved attribute is 

I) any attribute of type xsd: id or 

II) any attribute for which id is the local part of its Qualified Name. 

2) If an r: License contains no r: LicensePart elements with an r: licensePartidRef attribute, 
then the semantics of that r : License are as if the r : licensePart Id attribute were removed from 
all r : LicensePart elements in that r: License with an r : licensePart Id attribute. 

NOTE 1 It is the intent of e)ll) to enable the useful definition and incorporation of other identification systems on 
r : LicensePart elements beyond the document-global xsd : ID-typed identifiers. 

NOTE 2 Circular references such as that shown in Example 1 are not allowed because, after one application of 
provision e), the semantics will be as shown in Example 2, which violates provision d)3). 

EXAMPLE 1 
<r :license> 

<r : grant Group licensePart Id^'x") 

<r : grant Group licensePart IdRef = "y " / > 

< /r : gran tGroup> 

<r :grantGroup licensePartId="y" > 

<r : grantGroup licensePart IdRef = "x" / > 
< /r : grant Group > 
</r :license> 

EXAMPLE 2 

<r:license> 

<r: grantGroup licensePartld^x" > 
<r : grantGroup> 

<r : grantGroup licensePart IdRef ="x" /> 
</r : grant Group > 
< fx : gran t Group > 

<r: grantGroup licensePartId="y ,i > 
<r : grantGroup > 

<r : grantGroup licensePartidRef ="y"/> 
< /r : gran t Group > 
< /r : grantGroup> 
</r:license> 

6.4 License issuers 

Let / be an r : License. Let k be the number of //r : issuer children of /. If k is not 1 , then the semantics of / 
is the same as the semantics of k independent r: License elements, one for each of the k //r: issuer 
children of /. Each of these k r: License elements A is Equal to /, except that A has only one A/r : issuer 
child and that child is Equal to the respective //r : issuer child. 

With the exception of signature verification, this processing step shall be carried out before the other License 
processing steps defined in this part of ISO/IEC 21000. In particular, it shall be carried out before 
r: licensePart id references, Variable references, and the testing of equality. 
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NOTE If * is 0, it follows that the semantics of / Is the same as the semantics of no r : License at all. In colloquial 
terms, If a License has no issuer, it has not been issued and so has no effect 

6.5 Variables 

6.5.1 Variable definition 

6.5.1.1 General 

A Variable is declared using an r : f orAii element. A Variable has a name, a set of bindings, a scope, and a 
set of eligible bindings. 

6.5.1.2 Variable name 

Let / be an r:forAii element. Let y be the Variable declared by/. Then the name of y is the value of 
fl@T : varName. 

6.5.1 .3 Variable bindings 

LetJT be the universe of XML elements. Let q be an authorization request. Let e be an authorizes Let /be an 
r :f orAll element. Lety be the Variable declared by/. Then the set of bindings of y with respect to q and e 
is defined to be that subset of X such that x in X is in the set of bindings of y with respect to q and e if and only 
if a new XML document containing the element x as the root element Matches each of the 
//nanXmlPatternAbstract children of /with respect to q and e. 

6.5.1 .4 Variable scope 

For any XML element x, let following**) be that set of XPath nodes selected by the XPath location path 

following- sibling: : */descendent-or-self : :node{ ) 

when evaluated with x as the contextual XPath node. For an r :f orAll element x t let redeclarations^) be 
that set of XPath nodes selected by the XPath location path 

following- sibling : : */descendent-or- self : : r : f orAll [ @r : varName=$f VarName ] 

when evaluated with x as the contextual XPath node and $fVarName as the value of x/@r: varName. Let/ 
be an nforAli element. Let y be the Variable declared by/ Then the scope of y is defined to be 
following^) less the union of all following(d) where each XPath node d is in redeclarations^). 

6.5.1 .5 Eligible Variable bindings 

Let X be the universe of XML elements. Let q be an authorization request. Let e be an authorizes Let /be an 
r - f orAll element. Let y be the Variable declared by/. Then the set of eligible bindings of y with respect to 
q and e is defined to be that subset of X such that x in X is in the set of eligible bindings of y with respect to q 
and e if and only if x is in the set of bindings of y with respect to q and e and for all elements x »n the scope of y 
W here xl@*- varRef is Equal to //@r: varName all of the following hold: 

either the expanded element name of x exactly matches that of x or x is substitutable for x using 

substitution groups, 

— either the type of x exactly matches that of x or the type of x derives, through any number of levels, from 
the type of x using type derivation, and 

if x is removed from its document and replaced with an element Equal to x, that document is still valid. 
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6.5.2 Variable referencing 



Let a be an r:LicensePart. If a/@r:varRef exists, then a shall have empty content and the value of 
a/@r : varRef shall be the name of some Variable whose scope includes a. 

NOTE Conceptually, the contents of a are determined by the bindings of the Variable it references, so a doesnt need 
to have its own content. 

6.6 Conceptually abstract elements and types 

If a conceptually abstract element appears in an r: License, it shall either have a type that is not 
conceptually abstract or appear in the form of a Variable reference, as described in 6.5.2. 

If a conceptually abstract type appears in an r: License, it shall belong to an element that either is not 
conceptually abstract or appears in the form of a Variable reference, as described in 6.5.2. 

6.7 Revocable 

A revocable is an ordered pair containing the following members, in order: 

a) a document and 

b) the r : Principal identifying the issuer of that document. 

6.8 Principal surpassing 

6.8.1 General 

Let a and b be r: Principal elements. Let A be the set representation of a as defined in 6.8.2. Let B be the 
set representation of b as defined in 6.8.2. Then b Surpasses a if and only if for every a in A there exists a p in 
B such that a is Equal to p. 

6.8.2 Principal set representation 

Let p be an r : Principal. If p is an nAiiPrincipais element, then the set representation of p is the 
union of the set representations of each p/r: principal child of p. If p is not an r :AllPrincipals 
element, then the set representation ofp is the one-member set containing onlyp. 

6.9 Derived grants and grant groups 
6.9.1 General 

Let a be an r : Grant or an r : GrantGroup. Let & be an r: Grant or an r : GrantGroup. Let q be an 
authorization request. Let e be an authorizer. Then a is Derived from b with respect to q and e if and only if 
either of the following are true: 

— a is one-step-derived from b, or 

— there exists some r : Grant or r : GrantGroup </> such that all of the following are true: 

— a is one-step-derived from <p with respect to q and e as defined in 6.9.2.1 , and 

— 4> is Derived from b with respect to q and e. 
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6.9.2 One-step-derived grants and grant groups 

6.9.2.1 General 

Let a be an r: Grant or an r : GrantGroup. Let b be an r: Grant or an r: GrantGroup. Let q be an 
authorization request. Let e be an authorizer. Then a is one-step-derived from b with respect to q and e if and 
only if at least one of the following is true: 

— a is Equal to b, 

— a is one-step-derived from b with respect to q and e as defined in 6.9.2.2, 

— a is one-step-derived from b with respect to q and e as defined in 6.9.2.3, or 

— a is one-step-derived from b with respect to q and e as defined in 6.9.2.4. 

6.9.2.2 One-step-derived grants and grant groups resulting from a Variable 

Let a be an r: Grant or an r : GrantGroup. Let b be an r: Grant or an r: GrantGroup. Let q be an 
authorization request. Let e be an authorizer. Then a is one-step-derived from b with respect to q and e if and 
only if both b/r : f orAll is not absent and, letting / be the first b/r : f orAll child of b , a is Equal to b except 
that 

— /is not present in a and 

— there exists an x in the eligible bindings of the Variable declared by / with respect to q and e such that, 
throughout the scope of that Variable in b, all elements having references to that Variable are replaced in 

a byjc. 

6.9.2.3 One-step-derived grants and grant groups resulting from a grant group 

Let a be an r: Grant or an rt GrantGroup. Let b be an r: Grant or an r: GrantGroup. Let q be an 
authorization request. Let e be an authorizer. Then a is one-step-derived from b with respect to q and e if and 
only if both b is an r: GrantGroup that has no child r:f orAll element and there exists a b/ri grant or 
b/r : grantGroup 0 such that a is Equal to 0 except that 

— fl/r: principal is Equal to an r : allPrincipals whose children are, in order, b/r : principal (if 
present) and p/ri principal (if present) and 

— a/r: condition is Equal to an r : allConditions whose children are, in order, bin condition (if 
present) and p/ri condition (if present). 

6.9.2.4 One-step-derived grants resulting from a delegation control 

Let a be an r: Grant or an r : GrantGroup. Let b be an r: Grant or an r: GrantGroup. Let q be an 
authorization request. Let e be an authorizer. Then a is one-step-derived from b with respect to q and e if and 
only if all of the following are true: 

— b/r: :delegationControl is present, 

for each fc/r:f orAll /, b/r :delegationControl, fc/r: principal, and all of their descendent 

elements that are within the scope of the Variable declared by /do not have references (see 6.5.2) to the 
Variable declared by/, 

— a has no child r : f orAll elements, 
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— a/r : delegat ionControl is absent, 

— a/r : principal is Equal to b/r : principal, 

— a/r : right is Equal to 7, 

— letting a be a/r : resource, a is Equal to b except that 

— o/r: delegat ionControl is an allowable destination delegation control of 
b/ri delegat ionControl with respect to q t e, and b as defined in 7.3.4.3, 

— a/r i principal is an allowable destination principal of b/r% delegat ionControl with respect to q, 
e, and b as defined in 7.3.4.1 , and 

— a/r x condition is an allowable destination condition of fc/r;delegationControl with respect to 
q, e t and b as defined in 7.3.4.2, and 

— a/r : condition is absent. 

NOTE By placing an r: delegat ionControl in an r: Grant or r : GrantGroup, the effect of delegation of that 
r : Grant or r : GrantGroup can be achieved. If Principal A issues a License to Principal B and enables delegation using 
an r: delegat ionControl, Principal B can then issue a similar License to Principal C who can then issue a similar 
License to Principal D, who might be the same as Principal B. If the Conditions in the License from Principal A to Principal 
B expire (they are no longer Satisfied), the Licenses to Principal C and Principal D are still valid. If this is not the intent of 
Principal A, Principal A can use appropriate Conditions and place appropriate r :DcConstraint elements in the 
r: delegat ionControl so that the Conditions applicable to Principal C and Principal D are at least as restrictive as 
(meaning they will expire no later than) those applicable to Principal B. 

6.10 Encrypted Elements 

In cases where an r: License, r: Grant, or r: GrantGroup has a child validating against the 
r:encryptedLicense, r : encrypt edGr ant, or r : encrypt edGr ant Group particle, respectively, that 
child shall represent (see 7.3.6) the encryption of the contents of the r: License, r: Grant, or 
r: GrantGroup, and this part of ISO/IEC 21000 excepting 6.10 shall apply to the clear-text form of the 
r: License, r: Grant, or r : GrantGroup. 



7 Core 

7.1 General 

This Clause specifies the syntax and semantics integral to the architecture. 

7.2 Core authorization context properties 

Table 3 specifies the authorization context properties relating to Clause 7 and the statements they represent. 
If a property has the name given in the first column of Table 3 and the value given in the second column of 
Table 3, then the statement represented by that property is the statement given in the third column of Table 3. 



Table 3 — Core authorization context properties 



Property name 


Property value 


Statement represented 


nexerciseMechanlsmO 


m 


m is an rrExerciseMecnanisra, and the mechanism indicated by 
m is used to effect the requested performance. 


r:freshness(m, b, z) 


true 


m is an r:RevocationMechanism, b is a revocable, r is a time 



18 



© ISO/IEC 2003 — All rights reserved 



ISO/IEC FDIS 21000-5:2003(E) 







instant, and the mechanism indicated by m for effecting revocation 
of a revocable guarantees that no revocation of b has been, is, or 
will be in effect before or at r. 


r:fulfillerO 


P 


p is an r: Principal, and p identifies the fulfiller (according to the 
semantics of the Right Member of the authorization request) for the 
requested performance. 



7.3 General core elements and types 
7.3.1 License 

7.3.1.1 General 

Additional normative semantics of r : License is given in 5.8, 6.3, 6.4, 6.6, and 6.10. 
NOTE Example Licenses can be found in Annex D and G.5. 

7.3.1.2 Title 

For an r: License /, each of the //r: title elements that are present shall provide a descriptive phrase 
about / that is intended for human consumption. 

EXAMPLE The content of an r : title element is displayed in a user interface. 

Automated processors shall not interpret semantically the contents of such //r: title elements. 

7.3.1.3 Inventory 

An r: inventory is a syntactic container of r: LicensePart elements. Automated processors shall not 
interpret semantically the contents of an r : inventory element. 

NOTE An r: Inventory element of an r: License provides a convenient place to define r:LicensePart 
elements without the definition site associating any particular semantics with the r : LicensePart elements. Usefully and 
usually, r: LicensePart elements in an r: inventory will have r:iicensePartid attributes so that they can be 
referenced elsewhere in the r: License. 

7.3.1.4 Otherlnfo 

For an r : License /, the //r : otherlnfo element, if present, shall provide additional information. Automated 
processors need not interpret semantically the contents of an //r: otherlnfo element. 

EXAMPLE A License creator might include in the r: otherlnfo element some information that is peripherally 
related to some authentication or authorization process. 

7.3.1 .5 License attributes 

For an r: License /, the //@r -.licenseld attribute, if present, shall provide the URI that identifies /. 
Automated processors need not interpret semantically the contents of any r: License attributes. 

7.3.1.6 Issuer 
7.3.1.6.1 In a License 

Let / be an r : License with one l/r : issuer u (see 6.4 for additional semantics of r : issuer in Licenses), u 
shall give information about the issuer of L 
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7.3.1 .6.2 In general 

Letu be an r: issuer, u/dsig: Signature, if present, shall be a signature (XMLDSIG) that may be used to 
establish which Principal the issuer is. 

NOTE If a License has been tampered with so that the digest value in the signature does not match the digest of the 
License, then the signature probably does not establish which Principal the issuer is, and therefore the tampered License 
does not follow the semantics of this subclause. In this way, signatures also serve as a way to ensure integrity and 
authenticity of Licenses. 

w/r: principal, if present, shall identify which Principal the issuer is. «/r: details, if present, shall give 
details about the circumstances under which the issuer issues. 

7.3.1.6.3 IssuerDetalls 

Let e be an nissuerDetails. s/rstimeOf issue, if present, shall indicate the specific date and time at 
which the issuer claims to have issued. Each t/r : revocationMechanism, if any are present, shall indicate 
a mechanism by which the issuer shall, if he later wishes to revoke his revocable for the document whose 
issuer information is given by the parent of e, effect his revocation of that revocable. 

EXAMPLE 
<r: details > 

<r:timeOf Issue>2003-07-01T00 : 00 : 00</r : timeOf Issue> 
<r : revocationMechanism) 
<r : revocat ionService > 

<r : serviceRef erence licensePartldRef ="uddiService"/> 
< /r : revocat ionService > 
< /r : revocationMechanism) 
</r: details) 




7.3.1 .6.4 RevocationMechanism 

Let m be an r : RevocationMechanism. The child of m shall indicate a mechanism for effecting revocation 
of a revocable, m/ri revocat ionService, if present, indicates that the service reference identified by 
m/r: revocat ionService/r: serviceRef erence is the mechanism for effecting revocation of a revocable. 

7.3.1.6.5 Signature recommendations 



When a dsig: Signature s is used in an r: Issuer in an r: License, there should be an 
s/dsig:SignedInf o/dsig: Reference element r such that 



— r/@dsig : URI is omitted and 



— r/dsig: Transforms is present and contains exactly two child dsig: Transform elements, both 
dsig: Transform children are empty, the dsig Algorithm attribute of the first dsig: Transform 
Child has the value urn:mpeg:mpeg21:2003:01-REL-R-NS:licenseTransf^rin > and the 
dsig: Algorithm attribute of the second dsig :Transform child has the value urmuddi- 
org : schemaCentricC14N: 2002-07-10. 

NOTE 1 This practice simplifies the process of determining exactly which pieces of an r : License have actually been 
signed. It also ensures that signatures are consistent with the Equal operation. 

NOTE 2 There can also be other .s/dsigtSignedinfo/dsig: Reference elements that reference items (such as 
metadata) external to the License. Such references would be included in the signature. The use of such references is 
beyond the scope of this specification. 

EXAMPLE 

<dslg : Signature> 

<dslg : Signedlnf o> 
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<dsig:CanonicalizationMethod Algorithm* "http: //www.w3 .org/TR/2001/REC-xml-cl4n- 

2 °° 103 5dsig:SignatureMethod Algorithm="http: //www.w3 .org/2000/09/xmldsig#rsa-shal"/> 
<dsig : Ref erence> 

< ds ig ; Trans forms > 

<dsig: Transform Algorithm^ "urn : mpeg : rapeg21 : 2003 : 01-REL-R- 

NS : 1±censeTr ^^™ ra ^ gf orm Algorlthmsi " urn : uddi-org : schemaCentrlcCl 4N : 2002- 07 - 10 " / > 
</dsig:Transforms> 

<dsig:DigestMethod Algorithm="http: //www. w3 .org/ 20 00/09 /xmldsig#shal /> 
<dsig;DigestValue>JX9QbKOQCo941tTExbjl/Q-=</dsig:DigestVaXue> 

< /dsig : Reference) 
< /dsig : Signedlnf o> 

<dsig : SignatureValue>DFgqOhh5QQ-=< /dsig : SignatureValue> 
<dsig : Keylnf o> 

<dsig : KeyValue> 

<dsig : RSAKeyValue> 

< dsig : Modulus >gOyM4ccy z A== < / dsig : Modulus > 
<dsig ; Exponent >AQABAA« < / dsig : Exponent > 
< /dsig : RSAKeyValue> 
</dsig:KeyValue> 
< /dsig : Keylnf o> 
< /dsig : Signature > 

7.3.1 .6.6 License transform 

Let t be a dsig: Transform element with a dsig: Algorithm attribute whose value is 
urn:mpeg:mpeg21:2003:01-REL-R-NS:licenseTransform. Let / be the most immediate r:License 
ancestor of u Then t emits as output I with all its //r: issuer children wholly removed except for that 
//r : issuer that contains t , which is kept, removing its dsig : Signature child instead. 

7.3.1.7 Recommendation on declaration of Namespaces used in a License 

An r: License should not rely on Namespace declarations to be imported from its context in its surrounding 
XML document. 

NOTE Following this recommendation greatly facilitates the ability to manipulate an r : License as a self-contained 
unit within Applications. It also helps ensure that namespace declarations are included in signatures. 

7.3.2 UcenseGroup 

An r- LicenseGroup is a syntactic container of r: License elements. There is no normative semantics for 
r : LicenseGroup. No semantics is conveyed by the presence of two r : License elements within the same 
r : LicenseGroup. 

NOTE This type exists merely due to the observation that it is often convenient to be able to use it as a container in 
XML documents. No use of it is made in this part of ISO/IEC 21000. 

7.3.3 ForAli 

The semantics of r :forAll is given in 6.5. 

7.3.4 DelegationControl 

7.3.4.1 Allowable destination principals 

Let p be an r: Principal, d be an r :delegationControl, q be an authorization request, e be an 
authorizer, and g be an r: Grant or r :GrantGroup. Then;? is an allowable destination principal of d with 
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respect to q t e, and g if and only if p is an Allowable Destination Principal of each d/r : dcConstraint child of 
d with respect to q, e, and g. 

NOTE Because an Allowable Destination Principal does not appear in a License, it and its descendents cannot have 
any references to Variables not declared within the Allowable Destination Principal itself. 

7.3.4.2 Allowable destination conditions 

Let c be an r: Condition, d be an r :delegationControl, q be an authorization request, e be an 
authorize^ and g be an r: Grant or r :GrantGroup. Then c is an allowable destination condition of d with 
respect to q, e, and g if and only if c is an Allowable Destination Condition of each d/r : dcConstraint child of 
d with respect to q y e, and g. 

NOTE Because an Allowable Destination Condition does not appear in a License, it and its descendents cannot have 
any references to Variables not declared within the Allowable Destination Condition itself. 

7.3.4.3 Allowable destination delegation controls 

Let S be an r :delegationControl, d be an r: delegationControl, q be an authorization request, e be 
an authorizer, and g be an r : Grant or r :GrantGroup. Then S is an allowable destination delegation control 
of d with respect to q, e, and g if and only if 6 is an Allowable Destination Delegation Control of each 
d/r i dcConstraint child of d with respect to q, e, and g. 

NOTE Because an Allowable Destination Delegation Control does not appear in a License, it and its descendents 
cannot have any references to Variables not declared within the Allowable Destination Delegation Control itself. 

7.3.5 NonSecureReference 

The semantics and processing associated with the type r: NonSecureReference are identical to those of 
dsig:ReferenceType, except that the semantics and processing associated with the 
dsig:DigestMethod and dsig:DigestValue elements found in ds ig: Refer enceType are omitted. 

7.3.6 EncryptedContent 

The type r: EncryptedContent modifies the semantics of its base type, xenc:EncryptedDataType. An 
r: EncryptedContent shall have an xenc:Type attribute with a value of 
http: //www.w3 .org/2001/04/xmienc#Content. (See XMLENC.) 

NOTE This value is the type associated with encrypting XML element content. 

The plaintext of an r: EncryptedContent element shall replace semantically the r: EncryptedContent 
element and thus become the content of said element's parent. In doing so, the plaintext shall conform to the 
schema of the parent as a whole. 

7.4 Core conceptually abstract elements and types 
7.4.1 LicensePart 

The element niicensePart is conceptually abstract. The type r: LicensePart is conceptually abstract. 
Because of the requirements given in 6.3 c) and 6.5.2, if the syntax of a particular derivation of the type 
r: LicensePart declares its content model as optional, the semantics of that optional content model, unless 
specified otherwise, is that it shall not be omitted in an r: LicensePart of that derivation unless that 
r: LicensePart has an r : licensePartldRef or rrvarRef attribute. 
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7.4.2 Principal 

The element r: principal is conceptually abstract, 
r : Principal shall identify a system entity. 



The type r: Principal is conceptually abstract. An 



7.4.3 Right 

The element r: right is conceptually abstract. The type r: Right is conceptually abstract. An r: Right 
shall identify an act. The semantic specification of each different particular kind of r: Right should indicate 
which kinds of r: Resource, if any, are to be used as the Resource Member of an authorization request 
having that kind of r : Right as the Right Member. 



7.4.4 Resource 

The element r: resource is conceptually abstract. The type r: Resource is conceptually abstract. An 
rs Resource shall identify an entity, quality, event, state, concept, substance, or anything else referred to by 
a noun. 



7.4.5 Condition 

The element r: condition is conceptually abstract. The type rs condition is conceptually abstract. The 
semantics specification of each different particular kind of rs condition shall indicate whether or not an 
r- condition of that kind is Satisfied with respect to a given authorization request and authorization story. 
An application that encounters an rs Condition of which it lacks semantic knowledge shall not consider the 
rs Condition Satisfied. 



7.4.6 AnXmlPatternAbstract 



7.4.6.1 General 

The element r s anXmlPatternAbstract is conceptually abstract. The type rs AnXmlPatternAbstract 
is conceptually abstract. The semantics specification of each different particular kind of 
r- AnXmlPatternAbstract shall indicate whether or not a given XML document Matches an 
r -AnXmlPatternAbstract of that kind with respect to a given authorization request and authonzer. An 
application that encounters an rs AnXmlPatternAbstract of which it lacks semantic knowledge shall not 
consider anything as Matching that rs AnXmlPatternAbstract. 



7.4.6.2 PrlnclpalPatternAbstract 

The element rsprincipalPatternAbstract is conceptually abstract. The type 

r: PrlnclpalPatternAbstract is conceptually abstract. An XML document shall not Match an 
rsprincipalPatternAbstract with respect to any given authorization request and authonzer unless that 
XML document contains exactly one rs Principal as the root element. 



7.4.6.3 RightPatternAbstract 

The element rsrightPatternAbstract is conceptually abstract. The type r : RightPatternAbstract 
is conceptually abstract. An XML document shall not Match an r: RightPatternAbstract with respect to 
any given authorization request and authorizer unless that XML document contains exactly one rs Right as 
the root element. 



7.4.6.4 ResourcePatternAbstract 

The element rsresourcePatternAbstract is conceptually abstract. The type 

rs ResourcePatternAbstract is conceptually abstract. An XML document shall not Match an 
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r : ResourcePat t emAbstract with respect to any given authorization request and authorizer unless that 
XML document contains exactly one r : Resource as the root element. 



7.4.6.5 ConditionPatternAbstract 



The element r: ConditionPatternAbstract is conceptually abstract. The type 

r: ConditionPatternAbstract is conceptually abstract. An XML document shall not Match an 
r : ConditionPatternAbstract with respect to any given authorization request and authorizer unless that 
XML document contains exactly one r : Condition as the root element. 



7.4.7 DcConstralnt 



The element ndcConstraint is conceptually abstract. The type r : DcConstraint is conceptually 
abstract. 

The semantics specification of each different particular kind of r : DcConstraint shall indicate whether or not 
a given r: Principal is an Allowable Destination Principal of an r : DcConstraint of that kind with respect 
to a given authorization request, authorizer, and r: Grant or r : GrantGroup. An application that encounters 
an r: DcConstraint of which it lacks semantic knowledge shall not consider anything as an Allowable 
Destination Principal of that r : DcConstraint. 

The semantics specification of each different particular kind of n DcConstraint shall indicate whether or not 
a given r: Condition is an Allowable Destination Condition of an r: DcConstraint of that kind with 
respect to a given authorization request, authorizer, and r: Grant or r: GrantGroup. An application that 
encounters an r: DcConstraint of which it lacks semantic knowledge shall not consider anything as an 
Allowable Destination Condition of that r; DcConstraint. 

The semantics specification of each different particular kind of r: DcConstraint shall indicate whether or not 
a given r : delegat ionControl is an Allowable Destination Delegation Control of an r: DcConstraint of 
that kind with respect to a given authorization request, authorizer, and r: Grant or r: GrantGroup. An 
application that encounters an r: DcConstraint of which it lacks semantic knowledge shall not consider 
anything as an Allowable Destination Delegation Control of that r : DcConstraint. 



7.4.8 TrustRoot 

The element r rtrustRoot is conceptually abstract. The type r: TrustRoot is conceptually abstract. The 
semantics specification of each different particular kind of r: TrustRoot shall indicate the set of r: Grant 
elements identified by an r: TrustRoot of that kind with respect to a given authorization request and 
authorizer. An application that encounters an r: TrustRoot of which it lacks semantic knowledge shall 
consider that r : TrustRoot as representing the empty set. 



7.4.9 ServiceDescription 

The element r:serviceDescription is conceptually abstract. The type r: ServiceDescription is 
conceptually abstract. An r: ServiceDescription shall describe a service. An r : ServiceDescription 
should indicate the address of, the interface to, the rules for interacting with, and the functionality provided by 
the service. An r : ServiceDescription may include additional information about a service. 

NOTE See 8.1 2 for some examples of concrete types derived from r : ServiceDescription. 

7.4.10 Property Abstract 



The element rrpropertyAbs tract is conceptually abstract. The type r:PropertyAbs tract is 
conceptually abstract. An r :PropertyAbstract shall identify a property that can be possessed by a 
Principal. 
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7.5 Core principals 

7.5.1 AllPrincipals 

Letp be an r: AllPrincipals. Then p identifies that system entity that is identified by each of the 
pin principal children of/?. 

EXAMPLE 

<r : allPrincipals > 

<r:keyHolder licensePartldRef- "Alice" /> 

<r : keyHolder licensePartldRef ="Alice2 w /> 
</r : allPrincipals > 

NOTE If p has no children, then, according to 6.8, any r : Principal Surpasses p. 

7.5.2 KeyHolder 

Let P be an r: KeyHolder. Then p identifies that system entity that possesses the cryptographic key 
indicated by the />/r:info element as determined by the semantics of dsig:KeyinfoType given in 
XMLDSIG. 

EXAMPLE 1 A Principal using public-key cryptography can be identified as that Principal that possesses the private 
key that corresponds to the public key given in an r : KeyHolder. 

EXAMPLE 2 

< r : keyHolder 1 icen s ePar 1 1 d= " Alice " > 
<r:info> 

<dsig :KeyValue> 

<dsig : RSAKeyValue> 

<dslg : Modulus >AliM4ccyzA=* =< /dsig : Modulus > 
<dsig : Exponent >AQABAA=«< /dsig : Exponent > 
</dsig : RSAKeyValue> 
< /dsig : Key Value > 
</r:lnfo> 
</r: keyHolder > 

7.6 Core rights 

7.6.1 Issue 

Let r be an r tissue. Then r identifies the act of including an r:Grant or r :GrantGroup as f/r:grant or 
//r : grantGroup when issuing an r: License /. 

If r is used as the Right Member of an authorization request, then the Resource Member of that authorization 
request shall be present and shall be an r : Grant or an r rGrantGroup. 

NOTE Several authorization requests apply to issuing an r : License /, one for each //r : grant or //r : grantGroup 
therein. 

7.6.2 Obtain 

Let r be an r : Obtain. Then r identifies the act of obtaining an r : Grant or r : GrantGroup as l/r r grant or 
Z/r rgrantGroup in an issued r: License /. 

If r is used as the Right Member of an authorization request, then the Resource Member of that authorization 
request shall be present and shall be an r : Grant or an r rGrantGroup and, letting X be the Authorization 
Context Member of that authorization request, XrifulfillerQ shall identify the Principal who is requested to be 
the issuer of /. 
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NOTE 1 The use of an r: Obtain can be conceptualized as an offer or advertisement possibly for the sale of some 
r: Grant or r :GrantGroup. Suppose there is an authorization proof for an authorization request having an r: Obtain 
as the Right Member, an accurate Authorization Context Member z t and a Trust Root Member R. If R represents a sole 
trusted root issuer that is the same Principal identified by 2*.r:fulfiller0, it is generally expected that that Principal indeed will 
fulfill the request to obtain, since he is ultimately responsible for permitting the act of obtaining. 

NOTE 2 If a Principal is permitted to obtain an r: Grant from another Principal, there is no implication that the other 
Principal is permitted to issue that r: Grant. 

NOTE 3 If a Principal is permitted to obtain an r : Grant, there is no implication that the Principal is permitted to do the 
things mentioned in that r: Grant until he actually obtains it, at which time the normal License semantics apply to the 
License that has the obtained r : Grant. 

EXAMPLE 
<r : grant > 

<r : keyHolder licensePart IdRef = "Alice " / > 
<r:obtain/> 

<r : grantGroup licensePart IdRef - "playAndAdapt " / > 
</r:grant> 

7.6.3 PossessProperty 

Let r be an r : PossessProperty. Then r identifies the act of claiming ownership of a property. 

If r is used as the Right Member of an authorization request, then the Resource Member of that authorization 
request shall be present and shall be an r :PropertyAbstract. 

NOTE An r: PossessProperty can be used to model the authorized bindings of names and other attributes to 
Principals as is done in X.509I 6 ! and other public key certificates. An r: PossessProperty can also be used to model 
group membership and roles. 

7.6.4 Revoke 

Let r be an r: Revoke. Then r identifies the act of utilizing a mechanism to effect the revocation of a 
revocable. 

If r is used as the Right Member of an authorization request, then the Resource Member of that authorization 
request shall be present and shall identify a revocable. 

NOTE 1 Issuing a License having an r: Grant having an r: Revoke does not effect any revocation. Rather, one 
typically issues a License having an r: Grant having an r: Revoke in order to allow other Principals to effect the 
revocation of a revocable. 

NOTE 2 Suppose one License allows a user to do something. Suppose a second License allows a second user to 
revoke a revocable for the first License. Typically the first user will not be involved with the second License. Rather, there 
will be a revocation mechanism indicated in the first license, and that revocation mechanism will rely on the second 
License to determine if (within the trust roots of that revocation mechanism) the second user's revoke is permitted. Then, 
the first user will rely on that revocation mechanism to determine whether the first License is still in force. 

NOTE 3 It is expected that many revocation mechanisms will have trust roots installed that allow an issuer (and only 
the issuer) of a License to revoke the revocable for his License and freely delegate that ability to others. 

NOTE 4 Because a revocation mechanism does not revoke but simply records the revocation, users do not check if the 
revocation mechanism is permitted to revoke. 

EXAMPLE 
<r : grant > 

<r : keyHolder licensePart IdRef = "Alice " / > 
<r: revoke/ > 

<r: revocable licensePartldRef = w licenseToBeRevoked" /> 
< /r: grant > 
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7.7 Core resources 

7.7.1 DigitalResource 

Let t be an r: DigitalResource. Then t identifies an arbitrary sequence of digital bits b, determined as 
follows: 

If t /r :anxml is present, then b is the character string that is the sequence of zero or more XML elements 

contained within t/r : anXmi. 

— If t/r i binary is present, then b is the bit sequence whose base64 encoding is the value of t/r : binary. 

— If r/r:secureindirect is present, then b is the bit sequence to which that element refers according to 
the semantics and processing associated with the type dsig : Refer enceType (XMLDSIG). 

— If t/r monsecureindirect is present, then b is the bit sequence to which that element refers according 
to the semantics and processing associated with the type r : NonSecureRef erence. 

— Otherwise, b is the bit sequence identified by the child of t, according to the semantics of that child. 

NOTE When using r:nonSecureindirect, the user should be comfortable with the fact that different executions 
of the process for determining the sequence of bits might yield different results. No cryptographic measures are in place 
to ensure the yielded sequence of bits is the expected one. 

EXAMPLE 

<r : digitalRe source licensePart Id= "video " > 

<r;nonSecureIndirect URI="http: //acme .org /my Video "/> 
< /r : digit alResource> 

7.7.2 Grant 

Let t be an r : Grant. Then t identifies the Resource that is an XML element Equal to u 
NOTE Additional semantics related to r : Grant elements is given in 5.7, 6.9, and 6.1 0. 

7.7.3 GrantGroup 

Let t be an r : GrantGroup. Then t identifies the Resource that is an XML element Equal to t. 
NOTE Additional semantics related to r : GrantGroup elements is given in 5.7, 6.9, and 6.1 0. 
EXAMPLE 

<r:grantGroup licensePartId="playAndAdapt" > 
<r s keyHolder licensePart IdRef = "Alice " / > 
<r : grant > 

<mx:play/> 

<r:digitalResource licensePart IdRef = "video" /> 
< /r: grant > 
<r :grant> 

<mx; adapt /> 

<r: digit alResource licensePart IdRef = "video" /> 
</r:grant> 
</ r : gran t Group > 

7.7.4 Revocable 

Let t be an r : Revocable. Then t identifies a revocable (/,/>), determined as follows: 
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— If f/dsig:SignatureValue is present, then, letting s be the dsig: SignatureType having a child 
Equal to r/dsig : SignatureValue, both / is the document to which s applies and p is the r : Principal 
identifying that issuer of / that is established by s. 



— If f/dsig : Reference is present, then both of the following are true: 
— f/dsig: Reference shall reference a dsig : SignatureType and, 



— letting s be that dsig: SignatureType, both / is the document to which s applies and p is the 
r: Principal identifying that issuer of / that is established by 5. 

— If t/r 1 licenseld is present, then both p is Equal to t/r : principal and / is the r : License where all of 
the following are true: 

— the value of l/@r : licenseld is the value of t/r : licenseld, 



— there is one l/r : issuer, and 



— l/r i issuer corresponds to p. 
EXAMPLE 

<r : revocable licensePartId="licenseToBeRevoked" > 

<r : licenseld>urn : acme : license :id:12345</r; licenseld> 
<r : keyHolder licensePart IdRef = " acme" / > 

< /r : revocable > 



7.7.5 ServiceReference 



Let t be an r : ServiceReference. Then t identifies a reference to a service. The service referred to by t is 
described by f/r: serviceDescription. If t/r : serviceParameters is present, the values of the 
reference-specific parameters needed to interact with the service according to r/r: serviceDescription 
are determined according to the following paragraph, letting p be r/r : serviceParameters. If 
tin serviceParameters is not present, no reference-specific parameters are needed to interact with the 
service. 

For each integer k between 1 and the number of p/r : datum elements, let d k be the k^p/r : datum element. If 
there are no elements following d k or if the element immediately following d k is not an r: transforms, then 
the value of the reference-specific parameter needed to interact with the service according to 
t/r z serviceDescription is the child of d k . If there is an element immediately following d k and that element 
is an r: transforms, then the value of the * m reference-specific parameter needed to interact with the 
service according to tin serviceDescription is determined by the semantics of that r: transforms as 
given in XMLDSIG for dsig :Transf ormsType and modified as follows: 

— the input to the first dsig: Transform is an XPath node-set containing the child of d k in the context of a 
new XML document containing that child as the root element, and 

— the output of the last dsig: Transform is the value of the k** reference-specific parameter needed to 
interact with the service according to t/r : serviceDescription. 

NOTE The interpretation, detailed processing, and passing to the service of the reference-specific parameters is 
necessarily service-specific and is thus not defined here. 

EXAMPLE 1 

<r: ServiceReference licensePartld^uddiService" > 
<sx:uddi> 

< sx : serviceKey> 

<SX:uuid>D04951E4-332C-4693-B7DB-D3DlDlC2111K/sx:uuid> 
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</sx:serviceKey> 
</sx:uddi> 
< /r : serviceRef erence) 

fr^sTSceReference licensePartia="anonymousService"> 
<sx : anonymousStateService/> 
<r : serviceParameters> 

<r: <sx^ateDistinguisher>5001EB7E-80BF-43f7-9065- 
7E98CE52279E</sx:stateDistinguisher> 

</r :datum> 
< /r : serviceParameters> 
< /r : serviceRef erence > 

7.8 Core conditions 
7.8.1 AllConditlons 

and 5. 
EXAMPLE 

<ri ^vai?SS" 

<r : exerc±seMechanism> 

^ZZl^ll^lno, X i censePartia R e f =-ud< ii Serv i ceV> 
< / r 5 exerciseService > 
< /r : exerciseMechanisra> 
< /r : allConditions > 

NOTE If c has no children, then c is Satisfied. 
7.8.2 ExerciseMechanlsm 

i m , / i, r / /?\ be an authorization request. Let (g, A, e) be an 

xnexerciseMechanism 0 - 

mechanism for effecting a performance. 

NOTE An r: ExerciseMechanlsm is particular* useful when used in coniunctlon with an r:Obtain (see Exampie 
distribution channel. 

EXAMPLE 2 A clerk may be permitted to insert records into a database only if he uses a particular (error-checking) 
user interface form designed for that purpose. 

EXAMPLE 3 An airline company may permit fts frequent ftyers to ticket for a reduced fare when ticketing via a 
particular online travel service. 

EXAMPLE 4 

<r : exerciseMechanism> 
<r : exerciseService> 
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<r:serviceReference licensePartldRef ="uddiService ,, /> 
</r:exerciseServ±ce> 
< /r : exerciseMechanism) 

7.8.3 ExKstsRight 

Let c be an r: Exist sRight. Let (p, r, t, v, Z, L f R) be an authorization request. Let (g, h, e) be an 
authorization story. Let rj be the c/r: grant or c/r*: grantGroup child of c, whichever is present. Let B be 

— the set of r: Grant elements identified by c/r : trustRoot with respect to (p, r, v, Z, L, R) and 
authorizer e, if c/r : trustRoot is present, or 

— R, if c/r : trustRoot is not present. 

Then c is Satisfied with respect to (p, r, t, v, X, Z,, R) and (g, A, e) if and only if there is an authorizer e such that 
both of the following are true: 

— if e is absent, then rj is a member of &, and 

— if £ is present, then, letting (/, x t i, a, 5) be the ordered five-tuple representation of e , all of the following are 
true: 

— /is a member of L, 

— 77 is Equal to one of the l/r : Grant or //r : GrantGroup children of /, 

— JT.r:issueTime(/, ^ is i, 

— X.r:issueContext(/, rj, o) is true, 

— the time instant i is no later in time than the start of time interval v, and 

— 5 is an authorization proof for the authorization request (n, 1, r?, a, L, 0) where xp is a time interval 
of zero length starting at 1. 

EXAMPLE 
<r: exist sRlght> 
<r: grant > 

<r : keyHolder licensePart IdRef » "Alice " / > 
<mx:play/> 

<r : dlgltalResource licensePart IdRef = "video" / > 
<r:validltylnterval licensePartldRef = "firs tMonth"/> 
</r: grant > 
< /r : existsRight > 

7.8.4 Fulfiller 

Let c be an r : Fulfiller. Let (p, r, r, v, 2*, L, R) be an authorization request. Let {g, h, e) be an authorization 
story. Then c is Satisfied with respect to (p, r, t, v, X, L, R) and fe, h, e) if and only if c/r : principal is Equal 
toX.r:fulfiller(). 

EXAMPLE 

<r;fulfiller> 

<r : keyHolder licensePart IdRef = " Alice " / > 
</r:fulfiller> 
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7.8.5 PrerequisiteRight 

Let c be an r . PrerequisiteRight. Let (p, r, f, v, X, L, JQ be an authorization request. Let fe. h t e) be an 
authorization story. Let G be 

— the set of r: Grant elements identified by c/r : trustRoot with respect to (p, r, r, v, Z, L, R) and 
authorizere, if c/r: trustRoot is present, or 

— R, if c/r : trustRoot is not present. 

Then c is Satisfied with respect to (p, r. r. v. X, L, *) and (g, *. e) if and only if there is an authorization proof for 
the authorization request (c/r : principal, c/r : right, c/r : resource, v, X, L, 6>). 

EXAMPLE 

<r : prerequisiteRight > 

<r s keyHolder licensePart IdRef = "Alice " / > 
<mx:play/> 

<r:digitalResource licensePartldRef =" video /> 
< /r : prerequisiteRight > 

7.8.6 RevocatlonFreshness 

Let c be an r , RevocatlonFreshness. Let <p t r, r, v, X, L, R) be an authorization request. Let (g h, e) be an 
authorization story. Then c is Satisfied with respect to (p, r, f, v, 2", Z, K) and fe, /i, e) »f and only if one of the 
following is true: 

— c is absent, or 

- both e is present and, letting (/, « i, a, s) be the ordered five-tuple representation of e and letting b be the 
revocable (/, ^ there exists an r :RevocationMechanism m and a time instant r such that all of the 
following are true: 

— m is Equal to one Of the //r : issuer/r : det ails/r : revocat ionMechanism elements, 

— r is greater than or equal to the start of v less the duration c/r : priorToStart , and 

— .F.r:freshness(m, b, x) is true. 

NOTE 1 Having an r , priorToStart of 0 would make it difficult, if not impossible, to have a ra^M 
that is Queried in real time because of the trouble with synchronizing the revocation query response wrth the start oMhe 
oeforrS^On toe Sher hand, an r : priorToStart of 0 does not pose much difficulty if the revocation mechanism ,s 
a £ Z ™ seS ou* evei knight and is valid until the next midnight, as freshness is guaranteec 
beiween the Zo midnights When using a revocation mechanism that is queried in real time, it is generally expected that 
the r : priorToStart will be set to an appropriate value for that mechanism. 

NOTE 2 r:prior To start can be negative. A negative r: priorToStart does not work if the revocation 
mechanism onfy guarantees freshness through the time at which it is queried 

guarantee freshness through some time in the future, a negative r » priorToStart can be used to require that freshness 
is guaranteed for some duration after the start of the performance. 

EXAMPLE 

<r:revocationFreshness licensePartld^revFreshness > 

<r : priorToStart >P1D< /r : priorToStart > 
< /r : revocationFreshness> 
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7.8.7 Validitylnterval 



Let c be an r : validitylnterval. Let (p, r, t, v, X, L, R) be an authorization request. Let (g, h, e) be an 
authorization story. Then c is Satisfied with respect to &?, r, t, v, X, L t R) and fe, A, e) if and only if both of the 
following are true: 

— if c/rmotBefore is present, the start of v is greater than or equal to the instant in time represented by 
the value of c/r : notBef ore, and 



— if c/r: not After is present, the end of v is less than or equal to the instant in time represented by the 
value Of c/r : not After. 

NOTE If r is / and t is an r : Grant or r : Gran tGroup. Then, c constrains when t can be included in an r : License 
/. It does not speak to the validity of /. An r: Grant or r:GrantGroup element in / can contain a different 
r : Validitylnterval from c. 

EXAMPLE 

<r: validitylnterval licensePartId="f irstMonth"> 

<r : notBef ore>2003-01-0lT00 : 00 : 00</r : notBef ore > 

<r rnotAf ter>2003-01-31T23 : 59 : 59</r : not After > 
< /r : validitylnterval> 



7.9 Core patterns 
7.9.1 General patterns 



7.9.1 .1 AnXml Expression 

Let a be an r : AnXmlExpression. Let x be an XML document. Let q be an authorization request. Let e be 
an authorizer. Then x Matches a with respect to q and e if and only if the expression contained in a evaluates 
to true over* according to the semantics of the expression language indicated by a/@r : lang, if present. 

When c/@r:iang is absent or its value is http://www.w3.org/TR/i999/REC-xpath-l999lli6, the 
expression contained in a is written in XPath and, if that expression is not of XPath type boolean, it is to be 
converted to such as if the XPath function boolean were applied. 

Applications that support the use of any form of patterns at all should support the use of the 
http://www.w3.org/TR/1999/REC-xpath-19991116 expression language in r: AnXmlExpression 

elements. 



EXAMPLE 

< r : f orAl 1 varName = " acmeVideos n > 

<r : anXralExpr e ss Ion >mx : diRef erence/mx : identifier [starts- with ( . , 
"urn : acme : video : " ) ] < /r : anXmlExpresslon> 
</r:forAll> 



7.9.1 .2 PatternFromLicensePart 



Let a be an r: PatternFromLicensePart. Let x be an XML document. Let m be the root element 
contained in x. Let q be an authorization request. Let e be an authorizer. Then x Matches a with respect to q 
ahde if and only if m is Equal to a/r:licensePart. 



7.9.2 Principal patterns - PropertyPossessor 

Let a be an r : PropertyPossessor. Let x be an XML document. Let m be the root element contained in x. 
Let ip t r, t, v, L, R) be an authorization request. Let e be an authorizer. Let e be 
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— the set of r : Grant elements represented by a/r : trustRoot with respect to (p, r, t, v, 2 t L, R) and e, if 
a/r: trustRoot is present, or 

— - R, if a/r z trustRoot is not present. 

Then x Matches a with respect to (p, r, t, v, Z t L, R) and e if and only if both m is an r Principal and there is 
an authorization proof for the authorization request (m, P, a/r z propertyAbstract , v, s t L, &). 

EXAMPLE 

<r : propertyPossessor licensePart Id= " acraeSubscriber " > 

< sx : propertyUrl definitions "urn : acme : subscriber" / > 

<r : trust edRoot Issuers licensePart IdRef ■ "acmeCA" / > 
< /r : propertyPossessor> 

7.9.3 Right patterns 

No other right patterns are defined in the Core Namespace. 

7.9.4 Resource patterns 
7.9.4.1 GrantGroupPattern 

Let a be an r : GrantGroupPattern. Let x be an XML document. Let m be the root element contained in x. 
Let q be an authorization request. Let e be an authorizer. Then x Matches a with respect to q and e if and only 
if all of the following are true: 

— m is anr: GrantGroup, 

— if a/r : principal is present, m/r : principal is Equal to a/r : principal, 

— for each c/r : principalPattern/r : anXmlExpression or 
a/r:principalPattern/r:principalPatternAbstract a that is present, a new XML document 
containing m/r principal as the root element Matches a with respect to q and e, 

— if a/r : condition is present, m/r : condition is Equal to a/r ; condition, 

— for each a/r : conditionPattern/r : anXmlExpression or 
a/r:conditionPattern/r rconditionPatternAbs tract a that is present, a new XML document 
containing m/r : condition as the root element Matches a with respect to q and e, 

— letting n be the number of a/r: grant, a/r sgrantPat tern, a/r : grantGroup, and 
a/r : grant GroupPat tern children of a, letting a k be the Jc* 1 a/r: grant, a/r : grant Pat tern, 
a/r : grantGroup, or a/r : grant GroupPat tern child of a, and letting [t k be the m/rz grant or 
m/r z grantGroup child of m, both of the following are true: 

— n is also the number of m/r z grant and m/r z grantGroup children of m, and 

— for each k from 1 to n, both of the following are true: 

— if a k is an r : Grant or anr: GrantGroup then p k is Equal to a k , and 

— if a k is an r: Grant Pat tern or an r: GrantGroupPattern then a new document containing 
fi k as the root element Matches a k , and 

— for each a/r z wholeGrantGroupExpression a that is present, x Matches a with respect to q and e. 
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EXAMPLE 

<r tgrantGroupPattern licensePartId="adaptAndPlayVideo w > 
<r: grant > 

<mx: adapt /> 

<r : digit alResource licensePart IdRef = "video " / > 
< /r: grant > 
<r: grant > 

<inx:play/> 

<r:digltalResource licensePartldRef =" video "/> 
</r: grant > 
</r:grantGroupPattern> 

7-9-4.2 Grant Pattern 

Let a be an r : Grant Pat tern. Let x be an XML document. Let m be the root element contained in x. Let q 
be an authorization request. Let e be an authorizer. Then x Matches a with respect to q and e if and only if all 
of the following are true: 

— m is an n Grant, 

— if a/r : principal is present, m/r : principal is Equal to a/r : principal, 

— for each a/r :principalPattern/r:anXmlExpression or 
a/r :principalPattern/r :principalPatternAbs tract a that is present, a new XML document 
containing m/r : principal as the root element Matches a with respect to q and e, 

— if a/r i right is present, m/r : right is Equal to a/r : right, 

— for each a/ri right Pat tern/r : anXmlExpress ion or 
fl/r:rightPattern/r:rightPatternAbstract a that is present, a new XML document containing 
m/r : right as the root element Matches a with respect to q and e, 

— if a/r : resource is present, m/r : resource is Equal to a/r : resource, 

— for each tf/r:resourcePattern/r:anXmlExpression or 
a/r iresourcePat tern/r : resourcePatternAbs tract a that is present, a new XML document 
containing m/r ; resource as the root element Matches a with respect to q and e, 

— if a/r : condition is present, m/r z condition is Equal to a/r : condition, 

— for each a/r:conditionPattern/r : anXmlExpress ion or 
a/r :conclitionPattem/r:conditionPatternAbstract a that is present, a new XML document 
containing m/r : condition as the root element Matches a with respect to q and e, and 

— for each a/r : wholeGrantExpression a that is present, x Matches a with respect to q and e. 

NOTE An a/r : rightPattern with no children can be used to cause an r : Grant g to Match a irrespective of which 
glx i right child it has. 

EXAMPLE 

<r : gran t Pat tern licensePart Id= "playVideo " > 
<rax:play/> 

<r :digitalResource llcensePartldRef = w video "/> 
< /r : grantPat tern> 

7.9.5 Condition patterns 

No other condition patterns are defined in the Core Namespace. 
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7.10 Core delegation constraints 

7.10.1 Conditiontncremental 

Let d be an r : Conditionlncremental. Let q be an authorization request. Let e be an authorizer. Let g be 
an r: Grant or r : Grant Group. Let p be an r: Principal. Let c be an r: Condition. Let S be an 
r : delegationControl. 

Then/? is an Allowable Destination Principal of d with respect to q, e, and g. 

Further c is an Allowable Destination Condition of d with respect to q, e, and g if and only , if either of the 
following are true: 

— c is Equal to g/r : condition, or 

— c is Equal to an r:allConditions element containing g/r: condition as its first child along with any 
number of other children. 

Further S is an Allowable Destination Delegation Control of d with respect to q y e, and g if and only if there is a 
S/r ; dcConstraint that is either Equal to d or Equal to an r:ConditionUnchanged element. 

7.10.2 ConditionUnchanged 

Let d be an r: Condi tionUnchanged. Let q be an authorization request. Let e be an authorizer. Let g be 
an r: Grant or r : GrantGroup. Let p be an r: Principal. Let c be an r: Condition. Let S be an 
r : delegationControl. 

Then p is an Allowable Destination Principal of d with respect to q, e, and g. 

Further c is an Allowable Destination Condition of d with respect to q, e, and g if and only if c is Equal to 
g/r : condition. 

Further S is an Allowable Destination Delegation Control of d with respect to q t e t and g if and only if there is a 
S/rz dcConstraint that is Equal to d. 

7.10.3 DepthConstraint 

Let d be an r: DepthConstraint. Let q be an authorization request. Let e be an authorizer. Let g be an 
r: Grant or r : GrantGroup. Let p be an r; Principal. Let c be an r: Condition. Let S be an 
r ; delegationControl. 

Then p is an Allowable Destination Principal of d with respect to q, e, and g. 
Further c is an Allowable Destination Condition of d with respect to q, e, and g. 

Further d is an Allowable Destination Delegation Control of d with respect to q, e, and g if and only if there is a 
S/r i dcConstraint z that is Equal to d t except that z/r: count is any nonnegative integer strictly less than 
d/rx count. 

7.10.4 ToConstraint 

Let d be an r: ToConstraint. Let q be an authorization request. Let e be an authorizer. Let g be an 
r: Grant or r : GrantGroup. Let p be an r: Principal. Let c be an r: Condition. Let 5 be an 
r : delegationControl. 
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Then p is an Allowable Destination Principal of d with respect to q, e t and g if and only if both of the following 
are true: 

— if d does not have at least one d/r : f orAll child element, then there is a d/rz principal that is Equal to 
p, and 

— if d has at least one d/r : f orAli child element, then, letting / be the first d/r : f orAll child of d, there is 
an r : ToConstraint t such that all of the following are true: 

— / is Equal to d, except that 

— /is not present in t and 

— there exists an x in the eligible bindings of the Variable declared by/ with respect to q and e such 
that, throughout the scope of that Variable in d, all elements having references to that Variable 
are replaced in t by*. 

— p is an Allowable Destination Principal of t with respect to q 9 e, and g. 
Further c is an Allowable Destination Condition of d with respect to q 9 e, and g. 

Further 6 is an Allowable Destination Delegation Control of d with respect to q, e, and g if and only if there is a 
6/r :dcCons train t z that is Equal to d except for the following variations: 

— z may make zero, one, or more additions of an r : f orAll child preceding any that may be present in d. 

— z may make zero, one, or more omissions of some d/r : principal that may be present in d. 

— z may make zero, one, or more replacements of some d/n principal ^that may be present in d by 
replacing it with an r:aliPrincipals element containing n as its first child along with any number of 
other children. 

EXAMPLE 

<r:delegationControl> 

<r : conditionlncremental/ > 
<r:depthCons train t> 

<r: count >3</r: count > 
</r:depthConstraint> 
<r : toConstraint> 

<r: for All varName="delegatedTo" > 

<r : property Possess or HcensePartldRef ="acmeSubscriber"/> 
</r:forAll> 

<r:keyHolder varRef ="delegatedTo"/> 
</r : toConstraint > 
< /r : delegat ionControl> 



7.11 Core trust roots 



7.11.1 TrustedRootGrants 

Let z be an r: TrustedRootGrants. Let q be an authorization request. Let e be an authorizes Then z 
identifies with respect to q and e the set R of all z/r : grant children of z. 

7.11.2 TrustedRootlssuers 

Let z be an r : TrustedRootlssuers. Let q be an authorization request. Let e be an authorizes Then z 
identifies with respect to q and e the set R of r : Grant elements such that for each z/r : principal child p of 
z there is exactly one r : Grant g in R such that all of the following are true: 
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— exactly one g/r:forAll is present with an r:varName attribute whose value is x and no element 
content, 

— g/r : principal is Equal to p, 

— g/r : right is Equal to 7, 

— g/r : resource is Equal to an r : resource element with an r : varRef attribute whose value is x and no 
element content, and 

— g has no other children. 
EXAMPLE 

<r:trustedRoot Issuers licensePartia>"acraeCA > 

<r : keyHolder licensePart IdRef - 9 acme ■ / > 
< /r : trustedRoot Issuers> 

7.12 Core service descriptions 

No other service descriptions are defined in the Core Namespace. 

7.13 Core properties 

No other properties are defined in the Core Namespace. 



8 Standard extension 

8.1 General 

This Clause specifies syntax and semantics peripheral to the architecture but still useful in many domains 
beyond multimedia. 

8.2 Standard extension authorization context properties 

Table 4 specifies the authorization context properties relating to Clause 8 and the statements they represent 
If a property has the name given in the first column of Table 4 and the value given «n the second column of 
Table 4; then the statement represented by that property is the statement given in the third column of Table 4. 

Table 4 — Standard extension authorization context properties 



Property name 


Property value 


Statement represented 


sx:cF(rf) 


true 


d Is an rrServiceDescription, and there is a state of 
communication failure with the service described by d. 


sx:cFC(d, p) 


c 


d is an rrServiceDescription, p is an ordered tuple, c is an 
r: condition, and the service described by d claims that this 
property may be used in an authorization context to establish 
permission for the requested performance. 


sx:eL(d, p) 


true 


d is an rrServiceDescription, p is an ordered tuple, and the 
service described by d claims that this property may be used in an 
authorization context to establish permission for the requested 
performance. 

NOTE It is generally expected that the value of the property 
named sx:eL(d, p) will be true when the number of performances in 
some class of which the requested performance is a member has 
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not yet reached its limit. 


sx'eLCld o) 




fi flfl r> QorvipoHocprinf ^An /i ic on nr/H oroH timid » io on 

a 10 an -l . otsrviceuescripiion, p 15 an urucicu lupic, n is an 

integer, and the service described by d claims that this property may 
be used in an authorization context to establish permission for the 
requested performance. 

NOTE It is generally expected that the value of the property 
named sx:eLC(</, p) will correlate to the number of performances in 
some class of which the requested performance is a member. 


sxifAO 


a 


a is an sx:AccountPayable, and a is the default 
sx: Account Payable to use for the requested performance. 


Sx:fF(</, p, a t r) 




d is an r:ServiceDescr±ption, p is an ordered tuple, a is an 
sx: Account Payable, x is a time instant, <p is an sx:Rate, and 
the service described by d claims that, at t, the amount of money 
indicated by <p is considered paid using the mechanism for making a 
paymeni inuicaiea oy a io tne account indicated oy a tor flat fees 
with respect to p. 

NOTE Services will vary in their policies for what they consider 
paid. Some services might have policies that only consider money 
paid after a payment is actually made. Others might consider 
money paid as soon as a bill is generated for it. Others might 
consider money paid when a considers it paid. 


sx:fG(fl) 




a is an sx: Account Pay able, <p is an sx: Rate, and the amount of 
money indicated by <f> is considered paid using the mechanism for 
making a payment indicated by a to the account indicated by a for 
the requested performance. The meaning of considered paid is 
payment mechanism-specific. 


sxrfPI(rf, p, v, a) 




d is an r:ServlceDescrlptlon, p is an ordered tuple, v is a time 
interval, a is an sx: Account Payable, <p is an sx:Rate, and the 
service described by d claims that, at the start of v, the amount of 
money indicated by # is considered paid using the mechanism for 
iiidixirig a paymeni inuicaieu oy a io ine account inoicaieo Dy a tor v 
with respect to p. 

NOTE Services will vary in their policies for what they consider 
paid. Some services might have policies that only consider money 
paid after a payment is actually made. Others might consider 
money paid as soon as a bill is generated for it. Others might 
consider money paid when a considers it paid. 


sx:fPUPP(d, p, <p, n, a) 


true 


d is an r:ServlceDescription, p is an ordered tuple, <ft is an 
sx:Rate, n is an positive integer, a is an sx: Account Payable, 
and the service described by d claims that this property may be 
used in an authorization context to establish permission for the 
requested performance. 

NOTE It is generally expected that the value of the property 
named sx:fPUPP(rf, p, fa n, a) will be true when the number of 
performances in some class of which the requested performance is 
a member has not yet reached the number of performances 
considered paid for using the mechanism for making a payment 
indicated by a to the account indicated by a at the rate given by the 
amount of money indicated by <f> per each package of n 
performances. 


sx:sA(rf, p) 


true 


d is an r :ServiceDescriptlon, p is an ordered tuple, and the 
service described by d claims that this property may be used in an 
authorization context to establish permission for the requested 
performance. 
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sx:sRVP(rf, p, v) 


a 


d is an r : ServiceDescription, p is an ordered tuple, v is a time 
interval, a is an sx:StateRef erenceValuePattern, and the 
service described by d claims that the children of a represent the 
state of the service throughout v with respect to p. 


sx:tC(rf, p, v) 


P 


d is an r: ServiceDescription, p is an ordered tuple, v is a time 
interval, p is an r: Principal, and the service described by d 
claims that, throughout v, p identifies the owner of some virtual 
token with respect to p. 

NOTE 1 Typically the virtual token would be identified entirely by 
in a corv/iro.cnorifir faQhinn hut for ^omp services mioht also be 
known to the service by other means. 

NOTE 2 Though no normative requirement is placed on how the 
service deals with the change of ownership of a virtual token, it is 
generally expected that many services will provide features to allow 
the ordered exchange of ownership from one Principal to another. 


sx:tD(fl) 


true 


a is a URI identifying a digital location, and the requested 
performance occurs in the digital location identified by a. 


SX:tL(a, b f w,x,y t z) 


true 


a is a Qualified Name identifying a country, b is a Qualified Name 
identifying a country subdivision, w is a string identifying a state, x is 
a string identifying a city, y is a postal code, z is a street address, 
and the requested performance occurs at z in y and in the city 
identified by x and in the state identified by w and in the country 
subdivision identified by b and in the country identified by a. 
NOTE Some Qualified Names identifying countries and country 
subdivisions are defined in Annex B. 

EXAMPLE 1 An example string identifying a state is a two-letter 
code for US states. 

EXAMPLE 2 An example postal code is a zip code. 


sx:\Q(d, p, t) 


n 


d is an r : ServiceDescription, p is an ordered tuple, r is a time 
instant, n is an integer, and the service described by d claims that, at 
t, n is the track query integral value managed with respect to p. 


sx:tR(rf, p) 


true 


d is an r: ServiceDescription, p is an ordered tuple, and the 
service described by d claims that it considers the requested 
nprformance tracked with resDect to o. 

NOTE Services will vary in their policies for what they consider 
tracked. Some services might have policies that only consider a 
performance tracked if they are contacted about it in a timely 
manner, such as before the performance begins or after it ends. 
Others might require that they be contacted at the end of the day in 
which the performance begins. 


sx:vlFD(</, p) 


r 


d is an r : ServiceDescription, p is an ordered tuple, r is a time 
instant, and the service described by d claims that t is the 
determined floating start time with respect to p. 
NOTE It is generally expected that the determined floating start 
time will correspond with the start of the first performance where the 

nufknn-votinn ^nntavt i icoH fr\ octaKfichoH nprmiQQinn for that 

autnonzaiion context useo io ooiciuiioiicu pciMnooiuu iui uwi 
performance has a property named sx:vlFD(rf, p). 


sx:vlF(rf, p) 


V 


d is an r : ServiceDescription, p is an ordered tuple, v is a time 
interval, and the service described by d claims that v is the 
determined floating interval with respect to p. 
NOTE It is generally expected that the start of the determined 
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floating interval will correspond with the start of the first performance 
where the authorization context used to established permission for 
that performance has a property named sx:vlF(</, p). 


sx:vTM(</, p, v) 


true 


a 10 ail x . oci viV/cUc9^i J-piJ-Oii, p lo clll UiUcicU lupie, V IS a lime 

interval, and the service described by d claims that all of v is valid 
metered time with respect to p. 


sx:vTMD(d, p t t) 


y 


d is an r:ServiceDescript±on, p is an ordered tuple, r is a time 
instant, y is a time duration, and the service described by d claims 
that the total duration of time before r that it has claimed, claims, or 
will claim as valid metered time with respect to p is j>. 



8.3 General standard extension elements and types 

8.3.1 AccountPayable 

Let a be an sx: AccountPayable. The child of a shall indicate a mechanism for making a payment and an 
account to pay. a/sx : payraentService, if present, indicates that the service reference identified by 
fl/sx : paymentService/r : serviceRef erence is the mechanism for making a payment and the account to 
pay is determined in a service-specific fashion, a/sx: aba, if present, indicates that the American Bankers 
Association routing number (ROUTINGABA) given by the value of a/sx :aba/sx: institution is the 
mechanism for making a payment and the account to pay is indicated by the routing number along with the 
account given by the value of a/sx : aba/sx : account. 

8.3.2 ProfileCompliance 

For an r: License /, each list member in the value of the //@sx:prof ileCompiiance attribute, if the 
attribute is present, shall provide a Qualified Name representing one profile with which the License is 
compliant. If present, this attribute need not provide a complete list of the profiles with which the License is 
compliant. Applications may ignore this attribute. If they do process it, they may ignore any members of the 
list. 

8.3.3 Rate 

Let <f> be an sx:Rate. Then <p indicates an amount of money whose amount (as a float number) is the value 
of ^sx: amount and whose currency is identified by the value of tf/sx : currency, if ^/sx : currency is 
present, or is USD, if <p/sx : currency is absent. 

NOTE Some Qualified Names identifying currencies are defined in Annex B. 

8.3.4 StateDKstlngulsher 

There is no normative semantics for sx: stateDistinguisher. 

NOTE This type exists merely due to the observation that it is often convenient to be able to use it within an r : Datum 
to hold simple content to distinguish which state pertains to an sx : statef ulCondition. 

EXAMPLE 

<sx:stateDistinguisher>5001EB7E-80BF-43f7-9065-7E98CE52279E</sx;stateDistinguisher> 

8.3.5 UddfKey 

Let k be an sx:UddiKey. If */sx:uuid is present, then the primary key represented by k is the value of 
*/sx : uuid. If */sx : uri is present, then the primary key represented by k is the value of klsx i url. 
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8.3.6 Uuid 

Let u be an sxiUuid. Then the value of u is a Universally Unique Identifier as defined in UDDIV2DSR. 

8.4 Standard extension conceptually abstract elements and types 

8.4.1 Name 

The element sxmame is conceptually abstract. The type sx:Name is conceptually abstract. An sx:Name 
shall identify a name that can be possessed by a Principal. 

NOTE An sx:Name can be used along with an sx: PossessProperty to associate a name with a Principal. Such 
associations allow other r: Grant elements to refer to Principals described by their names. 

8.4.2 StatefulCondition 

The type sx: StatefulCondition is conceptually abstract. Let c be an sx: StatefulCondition. Let e 
be an authorizer. 

If c/r : serviceRef erence is present, the state reference of c with respect to e is c/r : serviceRef erence. 

If c/r : serviceRef erence is absent and e is absent, the state reference of c with respect to e is undefined. 

If c/r : serviceRef erence is absent and e is present, then, letting (/, i, a, s) be the ordered five-tuple 
representation of e, the state reference of c with respect to e is an r: ServiceRef erence m such that 
m/r: serviceDescription is Equal to an sx : anonymous Stat eService element, there is exactly one 
m/r : service Paramet er s/r : datum, and the child of that r : datum element is Equal to /. 

8.5 Standard extension principals 

No other principals are defined in the Standard Extension Namespace. 

8.6 Standard extension rights - RightUri 

Let r be an sx : RightUri. Then r identifies the act identified by r/@sx : definition. 
EXAMPLE 

<sx : rightUri def inition="urn : acme : copy" / > 

8.7 Standard extension resources 

No other resources are defined in the Standard Extension Namespace. 

8.8 Standard extension conditions 
8.8.1 CallForCondition 

Let c be an sx: CallForCondition. Let (p, r, /, v, X, L, R) be an authorization request. Let (g, h, e) be an 
authorization story. Then c is Satisfied with respect to (p, r, t, v, L 9 R) and (g, h, e) \f and only if there is a 
c/r: serviceRef erence m such that, letting p be the ordered tuple containing the values of the reference- 
specific parameters determined bym, Xsx:cFC(/n/r: serviceDescription, p) is Satisfied with respect to (p, 
r, f, v, £,L,R) and (g, h, e). 

EXAMPLE 

< sx : callForCondit ion> 

<r : serviceRef erence licensePart IdRef = " uddiService " / > 
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</sx : callForCondition> 

8.8.2 ExerciseLimit 

Let c be an sx: ExerciseLimit. Let (p, r, t, v, JT, L, R) be an authorization request. Let (g, A, e) be an 
authorization story. Let m be the state reference of c as defined by 8.4.2 with respect to e. Then c is Satisfied 
with respect to (p, r, t, v, X, I,, tf) and (g, /t, e) if and only if either m is undefined or, letting p be the ordered 
tuple containing the values of the reference-specific parameters determined by m, both of the following are 
true: 

— if c/sx: count is present, Xsx:eLC(m/r: serviceDescript ion, p) is less than or equal to the value of 
c/sx : count , and 

— if c/sx ; count is absent, 2lsx:eL(m/r : serviceDescript ion, p) is true. 
EXAMPLE 

< sx : exerci seLiroi t > 

<r : serviceRef erence licensePart IdRef = " anonymous Service " / > 

< sx : count > 3 < / sx : count > 
< / sx : exerc i s eLirai t > 

8.8.3 FeeFlat 

Let c be an sx: FeeFlat. Let {p, r, r, v, Z % L, R) be an authorization request. Let (g, h, e) be an authorization 
story. Let t be the time instant at the start of v. Let a be c/sx: to, if c/sx: to is present, or XsxrfAO, if 
c/sx: to is absent. Let m be the state reference of c as defined by 8.4.2 with respect to e. Then c is Satisfied 
with respect to (p, r, /, v, L, R) and fe, h, e) if and only if either m is undefined or, letting p be the ordered 
tuple containing the values of the reference-specific parameters determined by m, 
XsxrfF(m/r : serviceDescript ion, p, a, t) indicates an amount of money that is greater or equal in amount 
to and of the same currency as the amount of money indicated by c/sx : rate. 

EXAMPLE 

< sx : f eeFlat xmlns : iso= "urn :mpeg :mpeg21 r 2003 : 01-REL-SX-NS : 2003 : currency" > 
<r : serviceRef erence licensePart IdRef = "uddiService " / > 
<sx:rate> 

< sx : amount > 1 . 0 0 </ sx : amount > 

<sx : currency >iso : JPY< /sx : currency > 
</sx:rate> 
<sx:to> 

<sx:aba> 

<sx:institution>123456789</sx:institution> 
< sx : accoun t > 9 8 7 6 5 4 3 2 1< / sx : accoun t > 
</sx.-aba> 
</sx:to> 
</sx:feeFlat> 

8.8.4 FeeMetered 

Let c be an sx: FeeMetered. Let (p, r, t, v, Z, L, R) be an authorization request. Let fe, h, e) be an 
authorization story. Let a be c/sx: to, if c/sx: to is present, or xsxrfAQ, if c/sx: to is absent. Then c is 
Satisfied with respect to tp, r, t, v, X, L, R) and (g, h, e) if and only if Xsx:fG(a) indicates an amount of money 
that is greater or equal in amount to and of the same currency as 

x X (y/z) x (floor(w/y) + B) 

where 

— x is the amount of money indicated by c/sx : rate, 
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— y is the numerical value of c/sx : by in seconds, 

— z is the numerical value of c/sx : per in seconds, 

— w is the numerical value of the duration of v in seconds, and 

— S is 1 if w mod y is greater than the numerical value of c/sx : phase in seconds and 0 otherwise. 
EXAMPLE 

<sx : f eeMetered xralns i iso="urn :mpeg :rapeg21 : 2003 : 01-REL-SX-NS : 2003 : currency > 
<sx:rate> 

<sx: amount >24.00</sx: amount > 

< sx : currency > i so : USD< / sx : currency > 
</sx:rate> 

< sx : per > P1D< / sx : per > 

< sx : by >PT1H< / sx s by > 

< sx : phase > PT3 0M< / sx : phase > 
</sx: f eeMetered > 

8.8.5 FeePerlnterval 

Let c be an sx: FeePerlnterval. Let (p, r, t, v, L, R) be an authorization request. Let fe, h, e) be an 
authorization story. Let a be c/sx: to, if c/sx: to is present, or Xsx:fA(), if c/sx: to is absent. Let m be the 
state reference of c as defined by 8.4.2 with respect to e. Then c is Satisfied with respect to (p, r, t, v, Z, L, R) 
and (g, h, e) if and only if either m is undefined or, letting p be the ordered tuple containing the values of the 
reference-specific parameters determined by m, both of the following are true: 

— for every time instant r in v there exists some time interval 6 such that both 8 contains r and 
r.sxrfPI(m/r:serviceDescription, p, <5, a) indicates an amount of money that is greater or equal in 
amount to and of the same currency as the amount of money indicated by c/sx : rate, and 

— there does not exist some time interval 6 such that z has a property named 
sx:fPI(Wr : serviceDescription, p, <5, a) and 3 is not equal in duration to the value of c/sx: per. 

EXAMPLE 

<sx: f eePerlnterval xralns : ±so="urn :mpeg :mpeg21 : 2003 : 01-REL-SX-NS : 2003 : currency > 
<r : serviceRef erence licensePartldRef =" uddi Service "/> 
<sx:rate> 

<sx : amount >5 . 00 </sx: amount > 

< sx : currency > iso : USD< / sx : currency > 
</sx:rate> 

< sx : per > P 1D< / sx : per > 
</sx: f eePerlnterval > 

8.8.6 FeePerllse 

Let c be an sx:FeePerUse. Let (p, r, t, v, X, L, R) be an authorization request. Let (g, h, e) be an 
authorization story. Let a be c/sx: to, if c/sx: to is present, or xsx:fA0, if c/sx: to is absent. Then c is 
Satisfied with respect to fr, r, t, v, X, L, R) and (g, h, e) if and only if XsxrfG(a) indicates an amount of money 
that is greater or equal in amount to and of the same currency as the amount of money indicated by 
c/sx : rate. 

EXAMPLE 

<sx: f eePerUse xmlns : iso="urn rmpeg : mpeg21 : 2003 : 01-REL-SX-NS : 2003 : currency > 
<sx:rate> 

<sx: amount >2.00</sx: amount > 
<sx : currency >iso : USD< /sx : currency) 
</sx:rate> 
< / sx : f eePerUse > 
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8.8.7 FeePerUsePrePay 



Let c be an sxrFeePerUsePrePay. Let (p, r, t, v, Z, L t R) be an authorization request. Let (g, h 9 e) be an 
authorization story. Let <p be c/sx:rate. Let n be the value of c/sx: initialNumberOf Uses, if 
c/sx:initialNumberOfUses is present, or 1 if c/sx: initialNumberOf Uses is absent. Let a bec/sx:to, 
if c/sx : to is present, or Xsx:fA(), if c/sx : to is absent. Let m be the state reference of c as defined by 8.4.2 
with respect to e. Then c is Satisfied with respect to (p, r, t 9 v, X, L 9 R) and {g 9 h, e) if and only if either m is 
undefined or, letting p be the ordered tuple containing the values of the reference-specific parameters 
determined bym, Z.sx:fPUPP(Wr : serviceDescription, p, <p 9 n 9 a) is true. 



EXAMPLE 

<sx: f eePerUsePrePay xmlns :±so=" urn :mpeg:rapeg21 : 2003 : 01-REL-SX-NS : 2003 : currency" > 
<r : serviceRef erence licensePartldRef ="uddiService"/> 
<sx:rate> 

<sx: amount >3 . 00 </sx: amount > 

< sx : currency > i so : USD< / sx : currency > 
</sx:rate> 

< sx : InitialNumberOf Uses >7 < /sx : Inl t lalNuroberOf Uses > 
< /sx : f eePerUsePrePay > 



8.8.8 SeekApproval 

Let c be an sx : SeekApproval. Let (p, r, /, v, X, L, R) be an authorization request. Let (g, h, e) be an 
authorization story. Let m be the state reference of c as defined by 8.4.2 with respect to e. Then c is Satisfied 
with respect to (p, r, /, v, Z t L, R) and (g, h 9 e) if and only if either m is undefined or, letting p be the ordered 
tuple containing the values of the reference-specific parameters determined by m, 
2*.Sx:sA(/7i/r : serviceDescription, p) is true. 

EXAMPLE 

< sx : seekApproval > 

<r s serviceRef erence licensePartldRef ="uddiService"/> 
< /sx : seekApproval > 



8.8.9 Territory 

Let c be an sx: Territory. Let (p, r, /, v, 1, L, R) be an authorization request. Let (g, h, e) be an 
authorization story. Then c is Satisfied with respect to (p, r, t, v, L, R) and (g, h, e) if and only if there is 
either at least one c/sx: domain child y of c such that i:.sxiD(j/sx:uri) is true or at least one 
c/sx: location child y of c such that there exists Qualified Names a and b and strings w f r, y, and z such that 
all of the following are true: 

— X.sx:tL(a, b, w 9 x t y t z) is true, 

— if j/sx: country is present, its value is a, 

— if j/sx: region is present, its value is b t 

— if j/sx:state is present, its value is w 9 

— if )/sx: city is present, its value is x, 

— if j/sx:postalCode is present, its value isy, and 

— if j/sx : street is present, its value is z. 
EXAMPLE 

< sx : territory xmlns : iso= "urn : mpeg : mpeg21 : 2003 : 01 -REL-SX-NS : 2003 : country" > 
<sx:location> 
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< sx : country >±so : US< / sx : country > 
</sx: location> 
<sx: domain > 

<sx : uri>urn : acme : domains : 123</sx : uri> 
</sx: domain > 
< / sx : t errit ory > 

8-8.10 TrackQuery 

Let c be an sx: TrackQuery. Let {p, r, u v, X, L 9 R) be an authorization request. Let (g, h, e) be an 
authorization story. Let r be the time instant at the start of v. Let m be the state reference of c as defined by 
8.4.2 with respect to e. Then c is Satisfied with respect to (p, r, t, v, 2*. L, R) and (g, K e) if and only if either m 
is undefined or, letting p be the ordered tuple containing the values of the reference-specific parameters 
determined by m, x.sx:tQ(m/r:serviceDescription, p, t) is both greater than or equal to the value of 
c/sxmotLessTlian, if c/sx:notLessThan is present, and less than or equal to the value of 
c/sx:notMoreThan, if c/sx : notMoreThan is present. 

EXAMPLE 

<sx: trackQuery> 

<r:serviceReference licensePartldRef =" uddi Service "/> 

< sx : not LessThan > 5 < / sx : no t Les sThan> 

< sx : notMoreThan > 1 0 < / sx : notMoreThan> 
< /sx : trackQuery> 

8-8.11 TrackReport 

Let c be an sx: TrackReport. Let (p, r, t, v, X, L, R) be an authorization request. Let fe, h t e) be an 
authorization story. Let m be the state reference of c as defined by 8.4.2 with respect to e. Then c is Satisfied 
with respect to (p, r, t, v, X, L, R) and (g, h, e) if and only if either m is undefined or, letting p be the ordered 
tuple containing the values of the reference-specific parameters determined by m, either 
2T.sx:tR(m/r:serviceDescription, p) is true or both the value of c/sx:communicationFailurePolicy 
is lax and <r.sx:cF(m/r ; serviceDescription) is true. 

EXAMPLE 

< sx : trackReport > 

<r: serviceRef erence licensePartldRef ="uddiService"/> 

< sx: coromunicationFailurePolicy>required</sx : coromunicationFailurePolicy> 
< / sx : trackReport > 

8.8.12 TransferControl 

Let c be an sx; TransferControl. Let (p, r, t, v, X, L t R) be an authorization request. Let fe, h, e) be an 
authorization story. Let m be the state reference of c as defined by 8.4.2 with respect to e. Then c is Satisfied 
with respect to (p, r, t, v, X, L, R) and fe, h, e) if and only if either m is undefined or, letting p be the ordered 
tuple containing the values of the reference-specific parameters determined by m t 
2*.sx:tC(/n/r: serviceDescription, p, v) is Equal top. 

EXAMPLE 
<r : grant > 

<r : delegationControl> 

<r : conditionUnchanged/ > 
<r : depthConstraint > 

<r : coun t > 1< /r : count > 
< /r : depthConstraint > 
</r ; delegationControl> 

<r rkeyHolder licensePartldRef =" Alice" /> 
<mx:play/> 

<mx : diRef erence licensePartldRef »" video" / > 
<sx : transf erControl> 
<r : serviceRef erence > 
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< sx : anonymous St ateService/ > 
<r : serviceParameters > 
<r:datum> 

<sx:stateDistinguisher>5001EB7E-80BF-43f 7-9065- 
7E98CE52279E</sx : stateDistinguisher> 
</r :datum> 
</r:serviceParameters> 
< /r : serviceRef erence> 
</sx: transferControl> 
< /r: grant > 



8.8.13 Valid itylntervalFloatlng 

Let c be an sx: Validity intervalFloating. Let (p, r, t, v, 2*, L t R) be an authorization request. Let (g, h, 
e) be an authorization story. Let m be the state reference of c as defined by 8.4.2 with respect to e. Then c is 
Satisfied with respect to (p, r, t, v, JT, L, R) and {g t h, e) if and only if either m is undefined or, letting p be the 
ordered tuple containing the values of the reference-specific parameters determined by m, both of the 
following are true: 

— if c/sx: duration is present, v is wholly contained within the interval starting at 
X.sx:vlFD(wi/r : serviceDescription, p) and lasting the value of c/sx : duration, and 

— if c/sx ; duration is absent, v is wholly contained within Xsx:vlF(Wr : serviceDescription, p). 
EXAMPLE 

<sx : validityIntervalFloating> 

<sx:duration>P2D</sx:duration> 
< /sx ; valid! tyIntervalFloating> 

8.8.14 Validity IntervalStartsNow 

Let c be an sx : VaiidityintervaistartsNow. Let (p, r, t, v, 2; L, R) be an authorization request. Let (g, h, 
e) be an authorization story. Then c is Satisfied with respect to (p, r, f, v, X, L, R) and (g, h, e) if and only if both 
of the following hold: 

— if c/sx : backwardTolerance is present, then both c/r: valid! tylnterval/r : notBef ore is present 
and its value is greater than or equal to the result of the start of v set backward by the value 
c/sx: backwardTolerance, and 

— if c/sx : f orwardTolerance is present, then c/r : validitylnterval/r ; notBef ore is either 

— absent or 

— present and less than or equal to the result of the start of v set forward by the value of 
c/sx : f orwardTolerance. 

NOTE This condition is especially useful when used in conjunction with an 
sx : Validity IntervalDurationPattern. 

EXAMPLE 

<sx: validity Intervals tart sNow> 
<r ;validitylnterval> 

<r: notBef ore>2003-06-25T00: 00 :00</r: notBef ore> 

<r :notAf ter>2003-07-25T23 : 59 : 59</r : not After > 
< /r : validitylnterval> 

<sx : backwardTolerance >PlD</sx : backwardTolerance > 
<sx: f orwardTolerance >P 2D </sx: f orwardTolerance > 
< /sx : validity!ntervalStartsNow> 
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8.8.15 ValidityTimeMetered 

Let c be an sx: ValidityTimeMetered. Let (p, r, t, v, Z, L 9 R) be an authorization request. Let (g, h, e) be 
an authorization story. Let m be the state reference of c as defined by 8.4.2 with respect to e. Then t is 
Satisfied with respect to fr?, r, t, v, ^, Z,, R) and (g, A, e) if and only if either m is undefined or, letting p be the 
ordered tuple containing the values of the reference-specific parameters determined by m, all of the following 
are true: 

— for every time instant r in v, there exists some time interval S such that both 
X.sx:vTM(m/r : serviceDescription, p 9 S) is true and 5 contains r, 

— if c/sx; duration is present, then, letting r be the time instant at the end of v, 
Xsx:vTMD(//i/r : serviceDe script ion, p, t) is less than or equal to the value of c/sx: duration, and 

— if c/sx: quantum is present, then there does not exist some time interval 6 such that both 
2\sx:vTM(w/r:serviceDescription, p, <5) is true and 5 is shorter in duration than the value of 
c/sx : quantum. 

NOTE When c/sx: duration is absent, it is generally expected that the state reference used will refer to a sen/ice 
that has its own limit as to how much time it claims as valid metered time. On the other hand, if c/sx : duration is 
present, the service will typically just keep track of how much time it claims as valid metered time but not impose any of its 
own limits. 

EXAMPLE 

< sx : validityTiroeMetered> 

< sx : duration>PTlH</sx : durat ion> 
<sx : quantum>PT15S< /sx : quantum) 

< / sx : validi tyTimeMet ered> 

8.8.16 ValidityTimePerlodic 

Let c be an sx: ValidityTimePer iodic. Let (p, r, t, v, Z t L t R) be an authorization request. Let fe, h, e) be 
an authorization story. Let a be the value of c/sx: start, b be the value of c/sx: period, x be the value of 
c/sx: phase if it is present or 0 otherwise, y be the value of c/sx: duration, and z be the value of 
c/sx: per iodcount if it is present. Then c is Satisfied with respect to (p, r, t, v, 2, L, R) and (g, h, e) if and 
only if for every time instant r in v there exists an integer n such that all of the following are true: 

— the inequalitya +/i xb +x <= r<=a + « xb +x +y holds, 

— if jc>= 0 then /i >= 0, 

— ifx<0then« >= 1, 

— if x >= 0 and c/sx : per iodCount is present then n <= z - 1 , and 

— if x < 0 and c/sx : periodCount is present then n <= z. 

NOTE This condition is useful to express time windows such as every weekend or the second week of every month. 
EXAMPLE 

< sx : validityTimePeriodiO 

<sx: start >2003-01-01T00: 00 :00</sx: start > 

< sx : period>P 1M< / sx : period> 
<sx:phase>P7D</sx:phase> 

<sx : duration >P2D< /sx : duration> 

< sx : periodCount > 1 2 < / sx : periodCount > 

< / sx : validityTimePeriodiO 
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8.9 Standard extension patterns 

8.9.1 General patterns 

8.9.1 .1 LicenseldPattern 

Let a be an sx: LicenseldPattern. Let x be an XML document. Let m be the root element contained in jr. 
Let (p, r, t, v, z 9 L, R) be an authorization request. Let (/, x, i, a, s) be an authorizer. Then x Matches a with 
respect to (p, r, /, v, X, L, R) and (/, x, i, a, s) if and only if both m contains only simple content and that simple 
content is the value of //@r : licenseid. 

8.9.1 .2 StateRef erenceValuePattern 

Let a be an sx: StateRef erenceValuePattern. Let x be an XML document. Let m be the root element 
contained in x. Let (p, r, t t v, 2, L, R) be an authorization request. Let e be an authorizer. Then x Matches a 
with respect to (p, r, t, v, 2; L, R) and e if and only if both m is an r : ServiceRef erence and, letting p be the 
ordered tuple containing the values of the reference-specific parameters determined by m, 
.T.$x:sRVP(7?t/r : serviceDescrlption, p, v) is a. 

NOTE An r : St ateRef erenceValuePat tern is typically used with an r : Obtain to give the user of the r : Grant 
with the r: Obtain an idea about the initial state of an r: ServiceRef erence that would appear in the r: Grant he 
would obtain. 

EXAMPLE 

<sx: stateRef erenceValuePat tern > 

< acme : value > 6 < / acme : value > 
</sx: stateRef erenceValuePat tern > 

8.9.2 Principal patterns 

No other principal patterns are defined in the Standard Extension Namespace. 

8.9.3 Right patterns 

No other right patterns are defined in the Standard Extension Namespace. 

8.9.4 Resource patterns - X509SubjectNamePattern 

Let a be an sx:X509SubjectNamePattern. Let x be an XML document. Let m be the root element 
contained in x. Let q be an authorization request. Let e be an authorizer. Then x Matches a with respect to q 
and e if and only if both m is an sx:X509SubjectName and the content of a is the root of the subject name 
tree as specified in ISO/IEC 9594-8 for the subject name identified by m. 

EXAMPLE 

<r: for All vaxName^acmeDlstributorCertif icates" > 

<sx:x509SubjectNamePattern>CN=Acme Distributor</sx:x509SubjectNamePattern> 
</r:forAll> 

8.9.5 Condition patterns - ValidityintervalDurationPattern 

Let a be an sx:ValiditylntervalDurationPattern. Let x be an XML document. Let m be the root 
element contained in x. Let q be an authorization request. Let e be an authorizer. Then x Matches a with 
respect to q and e if and only if both m is an riValiditylnterval and the duration of the interval 
represented by m is equal to the value of a/sx : duration. 

NOTE This pattern is useful to express intervals that are fixed at some License issuing step, either for business 
model reasons or to minimize the amount of state keeping done by a compact device. 
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EXAMPLE 

< sx : validity IntervalDurat ionP at t ern> 

< sx : dura t ion > P 1M< / sx : dur a t ion> 
< / sx : validity In t ervalDura t ionPa t t ern > 

8.10 Standard extension delegation constraints 

No other delegation constraints are defined in the Standard Extension Namespace. 

8.11 Standard extension trust roots S 
No other trust roots are defined in the Standard Extension Namespace. 

8.12 Standard extension service descriptions 




8.12.1 AnonymousStateService 

Let d be an sx: AnonymousStateService. Then the service described by <><is implementation dependent 
and provides the following functionality. 

— With respect to any requested performance, for any ordered tuple p &t6 £"./ integer n, it sha\'l not claim 
that the authorization context property with name sx:el_C(d, p) and value n may be used in an 
authorization context to establish permission for the requested performance unless there are exactly « 
performances, including the requested performance, for which both of the following are true: 

— the authorization context used to establish permission for that performance has a property named 
sx:eLC(rf, p), and 

— the interval of time in which that performance occurs starts before or at the start of the interval of time 
in which the requested performance would occur. 

— For any ordered tuple p, any time interval v, and any r : Principals, it shall not claim that, throughout v, 
p identifies the owner of a virtual token it identifies by p if it has already claimed that during some time in v 
some other Principal is the owner of that same virtual token identified by p. 

— For any ordered tuple p, any time instant r, and any integer n, it shall not claim that, at r, n is the track 
query integral value managed with respect to p unless there are exactly n performances, including the 
requested performance if both of the following are true for it, for which both of the following are true: 

— the authorization context used to establish permission for that performance has a property named 
sx:tR(<f, p), and 

— the interval of time in which that performance occurs starts before or at t. 

— For any ordered tuple p and any time instant t, it shall not claim that x is the determined floating start time 
with respect to p if it has already claimed that some other time instant is the determined floating start time 
with respect to p. 

— For any ordered tuple p and any time interval v, it shall not claim that v is valid metered time with respect 
to p if making this claim would contradict any claims it has already made about total duration of valid 
metered time. 

— For any ordered tuple p, any time instant t, and any time duration y, it shall not claim that the total 
duration of time before rthat it has claimed, claims, or will claim as valid metered time with respect to p is 
y if it has already made claims about valid metered time that would result in more total duration thany. 
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— For any ordered tuple p r any sx: AccountPayable a t any time instant r, and any sx:Rate <f>, it shall not 
claim that, at r, the amount of money indicated by </> is considered paid using the mechanism for making a 
payment indicated by a to the account indicated by a for flat fees with respect to p if it has already claimed 
that, at r, a greater amount of money than that indicated by </> is considered paid using the mechanism for 
making a payment indicated by a to the account indicated by a for flat fees with respect to p. 



— For any ordered tuple p, any time interval v, any sx: Account Payable a, and any sx:Rate <f>, it shall 
not claim that, at the start of v, the amount of money indicated by # is considered paid using the 
mechanism for making a payment indicated by a to the account indicated by a for v with respect to p if it 
has already claimed that, at the start of v, a greater amount of money than that indicated by </> is 
considered paid using the mechanism for making a payment indicated by a to the account indicated by a 
for v with respect to p. 



8.12.2 Uddi 

Let d be an sx:Uddi. Let r be the Registry named by d/sxi registry, if it is present, or the Universal 
Business Registry, if d/sx : registry is not present. Then the description of the service described by d is 
given by the Business Service indicated by the primary key represented by d/sx : serviceKey (according to 
the semantics of sx : UddiKey) within the Registry r. 

EXAMPLE 

<sx:uddl licensePartId="uddiDescription" > 

<sx: serviceKey > 

<SX:UUid>D04951E4-332C-4693-B7DB-D3DlDlC21111</sx:uuid> 

< / sx : serviceKey > 
</sx:uddi> 



8.12.3 WsdIAddress 



Let d be an sx: wsdlAddress. Then <//sx:kind/sx:wsdl shall identify a wsdl: definitions element, 
and the description of the service described by d is given in that wsdl : definitions element for the WSDL 
binding whose name is the value of d/sx : kind/sx : binding. The endpoint of the service is given by the 
contents of d/sx i address. 

EXAMPLE 

< sx : wsdlAddress xmlns : ts="urn : TrackingService" > 
<sx:kind> 
<sx:wsdl> 

<r : nonSecurelndirect URI= "ht tp : / /services . acme . org/wsdl/ trackingService . wsdl" / > 
</sx: wsdl> 

<sx : binding>t s : TrackPrintSoapBinding< /sx : binding> 
</sx:kind> 
<sx: address > 

<soap : address locations "http : //services . acme . org/ trackingService" /> 
</sx: address > 
< / sx : wsdlAddress > 

8.12.4 WsdIComplete 

Let d be an sx:WsdlCompiete. Then <//sx:wsdi shall identify a wsdl: definitions element, and the 
description of the service described by d is given in that wsdl: definitions element for the WSDL service 
whose name is the value of d/sx : service. If J/sx:portType is present, it limits the description only to 
those WSDL ports whose WSDL port type is the one whose name is the value of d/sx : portType. 

EXAMPLE 

<sx : wsdlComplete xmlns : ts= "urn : TrackingService " > 
<sx: wsdl> 

<r : nonSecurelndirect URI= "ht tp : //services . acme . org/wsdl/ trackingService . wsdl " / > 
</sx:wsdl> 
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<sx : service> t s : TrackPrint < /sx : service) 
</sx: wsdlComplete> 

8.13 Standard extension properties - PropertyUri 

Let t be an sx : PropertyUri. Then t identifies the property identified by f/@sx : definition. 
EXAMPLE 

< sx : propertyUri def init ion= " urn : acme : distributor" / > 

8.14 Standard extension name properties 

8.14.1 CommonName 

Let t be an sx: CommonName. Then t identifies the common-name indicated by the contents of t as specified 
in ISO/IEC 10021-2. 

8.14.2 DnsName 

Let t be an sx: DnsName. Then / identifies the domain name with trailing period omitted indicated by the 
contents of t as specified in RFC 1034. 

EXAMPLE 

< sx : dnsNarae >prof es sor . acme . org< / sx : dnsName > 

8.14.3 Email Name 

Let t be an sx:EmailName. Then t identifies the Internet email address indicated by the contents of t as 
specified in RFC 2822. 

EXAMPLE 

< sx : emailName>alice@acme . org< /sx : emailName > 

8.14.4 X509Sub|ectName 

Let t be an sx:X509Sub jectName. Then t identifies the subject name that is the contents of / as specified in 
ISO/IEC 9594-8. 

EXAMPLE 

<sx:x509SubjectName>CN=Alice</sx:x509SubjectName> 



9 Multimedia extension 

9.1 General 

This Clause specifies syntax and semantics specific to multimedia. 

9.2 Multimedia extension authorization context properties 

Table 5 specifies the authorization context properties relating to Clause 9 and the statements they represent. 
If a property has the name given in the first column of Table 5 and the value given in the second column of 
Table 5, then the statement represented by that property is the statement given in the third column of Table 5. 
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Table 5 — Multimedia extension authorization context properties 



Property name 


Property value 


Statement represented 


mx:destination0 


P 


p is an r: Principal, and p identifies the destination repository 
(according to the semantics of the Right Member of the 
authorization request) for the requested performance. 


mx:didl(r, t) 


d 


/ is an mx:DlReference; d is a didl : Container, 
Qiui : uescnpLor, aiai : iieni t aiai : component, Of 

didl: Anchor; r is a time instant; and, at r, </ declares the 
Container, Descriptor, Digital Item, Component, or Fragment 
identified by t. 


mx:helpersO 


P 


P is a set of r: Principal elements, and P is the exact set of 
elements where both each element identifies one piece of software 
helping in the requested performance and every piece of software 
helping in the requested performance is identified by some element 
ini> 


mx:mark(a, b) 


true 


a is an r: Resource, b is an element that describes a mark, and, 
during the course of the requested performance, the Resource 
identified by a becomes marked as described by b. 


mx:marked(<z, b, x) 


true 


a is an r z Resource, b is an element that describes a mark, r is a 
time instant, and, at r, the Resource identified by a is already 
marked as described by b. 


mxrpartOffa, b t t) 


true 


a is an mx : DIRef erence, b is an mx:D!Reference, r is a time 
instant, and, at r, the Container, Descriptor, Digital Item, 
Component, or Fragment identified by a is (through any number of 
levels) a part of the Container, Descriptor, Digital Item, Component, 
or Fragment identified by b. 


mxrrACO 


A 


A is a set of resource attributes, and A is the exact set of resource 
attributes that are changed (according to the semantics of the Right 
Member of the authorization request) during the course of the 
requested performance on the Resource identified by the Resource 
Member of the authorization request. 


mx:renderersO 


P 


P is a set of r: Principal elements, and P is the exact set of 
elements where both each element identifies one Principal that 
renders some component of the Resource identified by the 
Resource Member of the authorization request into its directly 
perceivable representation for the requested performance and every 
Principal that renders some component of the Resource Identified 

bv the Resource Member of the authorisation rpnup<:t into itQ Hirorth/ 
perceivable representation for the requested performance is 
identified by some element in P. 

EXAMPLE Audio cards and video cards are examples of 
Tenderers. 

NOTE This property is used with render rights. 


mx:sigFound(s, t) 


true 


5 is a dsig : Signature, t is a time instant, and s exists at t. 


mx:sigRefValid(s,/, /, t) 


true 


s is a dsig: Signature, / is a dsig: Reference, t is an 
r: Resource, r is a time instant, and, at t, Digital Signature 
Reference Validation of s succeeds when the data object to be 
digested for / is obtained (as is called for in XMLDSIG 3.2.1.2.1) 
using, instead, t. 


mx:sigSigValid(s,p, t) 


true 


s is a dsig : Signature, p is an r : Principal, r is a time instant, 
and, at r, Digital Signature Signature Validation of s succeeds when 
the keying information is obtained (as is called for in XMLDSIG 
3.2.2.1) using, instead,/?. 
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mxrsourceO 


P 


p is an r: Principal, and p identifies the source repository 
(according to the semantics of the Right Member of the 
authorization request) for the requested performance. 


mx:tXA(rf, p) 


true 


d is an r:ServiceDescription, p is an ordered tuple, and the 
service described by d claims that this property may be used in an 
authorization context to establish permission for the requested 
performance. 

NOTE It is generally expected that the value of the property 
named mx:tXA(d, p) will be true if the service is utilized to perform 
one transaction for the purposes of the requested performance. 



9.3 General multimedia extension elements and types - resource attribute set definitions 

9.3.1 Complement 

Let s be an mx: complement. Then the set identified by s is the complement (under the universe of all 
resource attributes) of the set identified by the resource attribute set definition element child of s. 

EXAMPLE 

<rax : complement > 

<mx: set definition="urn:osmaker:fileProperties"/> 

< /tax i complement > 

9.3.2 Intersection 

Let s be an mx: intersection. Then the set identified by s is the intersection of the sets identified by the 
resource attribute set definition element children of s. s may have no resource attribute set definition element 
children even if it also has no r : licensePartidRef or r :varRef attribute; in this case the set identified by 
s is the universe of all resource attributes. 

EXAMPLE 

<mx: intersection> 

<mx : set definition^ "urn ; acmepubl : bookProperties " / > 
<mx : set def inition= "urn : acmepub2 : bookProperties " / > 

< /mx : intersection 

9.3.3 Set 

Let 5 be an mx : set. Then the set identified by s is the set that is defined by the URI sf@mx : definition. If 
that definition requires any parameters, they shall be provided as the content of s. 

EXAMPLE 

<mx : set definitions "urn : osraaker : f ileProperties " / > 

9.3.4 Union 

Let s be an mx: union. Then the set identified by s is the union of the sets identified by the resource attribute 
set definition element children of s. s may have no resource attribute set definition element children even if it 
also has no r : licensePartidRef or r : varRef attribute; in this case the set identified by 5 is the empty set. 

EXAMPLE 
<mx: union > 

<mx: set definition "urn : acmepubl : bookProperties" /> 
<mx : set def init ion= "urn : acmepub2 : bookProperties " / > 
</mx:union> 
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9.4 Multimedia extension conceptually abstract elements and types 

No other conceptually abstract elements and types are defined in the Multimedia Extension Namespace. 

9.5 Multimedia extension principals 

No other principals are defined in the Multimedia Extension Namespace. 

9.6 Multimedia extension rights 

9.6.1 Adapt 

Let r be an mxz Adapt. Then r identifies the act of Adapt as defined in ISO/IEC 21000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the SourceOf Adaptation as defined in ISO/IEC 21000- 
6 and, letting 2 be the Authorization Context Member of that authorization request, both x.mx:source() shall 
identify the repository that is the PlaceOfAdaptingFrom as defined in ISO/IEC 21000-6 and -F.mx:destination() 
shall identify the repository that is the PlaceOfAdaptingTo as defined in ISO/IEC 21000-6. 

NOTE 1 An mx: Adapt identifies the act of changing transiently an existing Resource to derive a new Resource. With 
an mx: Adapt, two distinct Resources will exist as a result of the process, one of which is the original Resource in 
unchanged form, and one of which is newly made. Changes can include the addition to and removal of elements of the 
original Resource, including the embedding of other Resources. Changes can be made temporarily to the original 
Resource in the course of the adapt process, but such changes are not saved in the original Resource at the end of the 
process. 

NOTE 2 An rax: Adapt can be used with Conditions requiring specific resource attributes of the Resource to be 
preserved or changed. The specific resource attributes can be on a list or can be called out by using a list. Lists can be 
inclusive (for example, "Attributes a and p must be changed") or exclusive (for example, "Everything except attributes y 
and 6 must be changed"). Resource attributes that are not otherwise constrained by Conditions can be changed. 

9.6.2 Delete 

Let r be an mx: Delete. Then r identifies the act of Delete as defined in ISO/IEC 21000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the DeletedResource as defined in ISO/IEC 21000-6 
and, letting Z be the Authorization Context Member of that authorization request, XmxisourceO shall identify 
the repository that is the PlaceOf Deleting as defined in ISO/IEC 21 000-6. 

NOTE An mx: Delete identifies the act of destroying a DigitalResource as defined in ISO/IEC 21000-6. Delete is not 
capable of reversal. After a delete process, an "undelete" action is impossible. 

9.6.3 Diminish 

Let r be an mx: Diminish. Then r identifies the act of Diminish as defined in ISO/IEC 21000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the SourceOf Diminution as defined in ISO/IEC 21000- 
6 and, letting z be the Authorization Context Member of that authorization request, both JT.mxisourceO shall 
identify the repository that is the PlaceOfDiminishingFrom as defined in ISO/IEC 21000-6 and 
2\mx:destination() shall identify the repository that is the PlaceOfDiminishingTo as defined in ISO/IEC 21000-6. 

NOTE An mx: Diminish identifies the act of deriving a new Resource which is smaller than its Source as defined in 
ISO/IEC 21000-6. With an mx: Diminish, two distinct Resources will exist at the end of the process, one of which is the 
original Resource in unchanged form, and one of which is newly made, whose content is adapted from the original 
Resource, and a measure of which is smaller than that of the original. Changes can include the removal of elements of 
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the original Resource. Changes can be made temporarily to the original Resource in the course of the diminish process, 
but such changes are not saved in the original Resource at the end of the process. 

9.6.4 Embed 

Let r be an mx: Embed. Then r identifies the act of Embed as defined in ISO/IEC 21000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the EmbeddedResource as defined in ISO/IEC 21000- 
6 and, letting 2 be the Authorization Context Member of that authorization request, both 2*.mx:source() shall 
identify the repository that is the PlaceOfEmbeddingFrom as defined in ISO/IEC 21000-6 and 
XmxrdestinationO shall identify the repository that is the PlaceOfEmbeddingTo as defined in ISO/IEC 21000-6. 

NOTE 1 An mx: Embed identifies the act of putting a Resource into another Resource. The Resource into which a 
Resource is embedded can be pre-existing or can be created by the act of combining the embedded Resource with one or 
more others. 

NOTE 2 An mx: Embed refers only to the embedding of an existing Resource in another. If a "copy" of an existing 
Resource is to be created and embedded in another, then both mx: Adapt and mx: Embed would be used. 

9.6.5 Enhance 

Let r be an mx : Enhance. Then r identifies the act of Enhance as defined in ISO/IEC 21 000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the SourceOfEnhancement as defined in ISO/IEC 
21000-6 and, letting Z be the Authorization Context Member of that authorization request, both XmxrsourceO 
shall identify the repository that is the PlaceOfEnhancingFrom as defined in ISO/IEC 21000-6 and 
xmxrdestinationO shall identify the repository that is the PlaceOfEnhancingTo as defined in ISO/IEC 21000-6. 

NOTE An mx: Enhance identifies the act of deriving a new Resource which is larger than its Source as defined in 
ISO/IEC 21000-6. With an mx: Enhance, two distinct Resources will exist at the end of the process, one of which is the 
original Resource in unchanged form, and one of which is newly made, whose content is adapted from the original 
Resource, and a measure of which is smaller than that of the original. Changes can include the addition to elements of 
the original Resource, including the embedding of other Resources. Changes can be made temporarily to the original 
Resource in the course of the enhance process, but such changes are not saved in the original Resource at the end of the 
process. 

9.6.6 Enlarge 

Let r be an mx : Enlarge. Then r identifies the act of Enlarge as defined in ISO/IEC 21 000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the EnlargedResource as defined in ISO/IEC 21000-6 
and, letting X be the Authorization Context Member of that authorization request, Xmx:source0 shall identify 
the repository that is the PlaceOf Enlarging as defined in ISO/IEC 21000-6. 

NOTE An mx: Enlarge identifies the act of modifying a Resource by adding to it. With an mx: Enlarge, a single 
Resource is preserved at the end of the process. Changes can include the addition of new material, including the 
embedding of other Resources, but not the changing or removal of existing elements of the original Resource. 

9.6.7 Execute 

Let r be an mx: Execute. Then r identifies the act of Execute as defined in ISO/IEC 21000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the Executed Resource as defined in ISO/IEC 21000-6 
and, letting X be the Authorization Context Member of that authorization request, x.mxrsourceO shall identify 
the repository that is the PlaceOfExecuting as defined in ISO/IEC 21000-6. 
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NOTE An mx: Execute identifies the act of executing a Digital Resource as defined in ISO/IEC 21000-6. An 
mx: Execute refers to the primitive computing process of executing. 

9.6.8 Install 

Let r be an mx: install. Then r identifies the act of Install as defined in ISO/IEC 21000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the InstallingResource as defined in ISO/IEC 21000-6 
and, letting 2 be the Authorization Context Member of that authorization request X.mx:source0 shall identify 
the repository that is the PlaceOf Installing as defined in ISO/IEC 21000-6. 

NOTE An mx: install identifies the act of following the instructions provided by an InstallingResource as defined in 
ISO/IEC 21000-6. 

9.6.9 Modify 

Let r be an mx ; Modify. Then r identifies the act of Modify as defined in ISO/IEC 21000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the ModifiedResource as defined in ISO/IEC 21000-6 
and, letting Xbe the Authorization Context Member of that authorization request, Xmx:sourceO shall identify 
the repository that is the PlaceOfModifying as defined in ISO/IEC 21 000-6. 

NOTE 1 An mx: Modify identifies the act of changing a Resource, preserving the alterations made. With an 
mx: Modify, a single Resource is preserved at the end of the process. Changes can include the addition to and removal 
of elements of the original Resource, including the embedding of other Resources. 

NOTE 2 An mx: Modify can be used with Conditions requiring specific resource attributes of the Resource to be 
preserved or changed. The specific resource attributes can be on a list or can be called out by using a list. Lists can be 
inclusive (for example, "Attributes a and p must be changed") or exclusive (for example, "Everything except attributes y 
and 6 must be changed"). Resource attributes that are not otherwise constrained by Conditions can be changed. 

9.6.10 Move 

Let r be an mx : Move. Then r identifies the act of Move as defined in ISO/IEC 21 000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the MovedResource as defined in ISO/IEC 21000-6 
and, letting S be the Authorization Context Member of that authorization request, both -F.mxrsourceO shall 
identify the repository that is the Origin as defined in ISO/IEC 21000-6 and x.mx:destination() shall identify the 
repository that is the Destination as defined in ISO/IEC 21000-6. 

NOTE An mxrMove identifies the act of relocating a Resource from one place to another. With an mx:Move, at least 
the location of the Resource is changed. 

9.6.11 Play 

Let r be an mx : Play. Then r identifies the act of Play as defined in ISO/IEC 21 000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the SourceOf Playing as defined in ISO/IEC 21000-6 
and, letting z be the Authorization Context Member of that authorization request, z.mxrsourceO shall identify 
the repository that is the PlaceOfPlayingFrom as defined in ISO/IEC 21 000-6. 

NOTE 1 An mx : Play identifies the act of deriving a transient and directly perceivable representation of a Resource. 
An mx : Play covers the making of any forms of transient representation that can be perceived directly (that is, without any 
intermediary process) with at least one of the five human senses. An mx: Play includes playing a video or audio clip, 
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displaying an image or text document, or creating transient representations that can be touched, or perceived to be 
touched. When an mx:Play is applied to a Digital Resource, content can be rendered in any order or sequence 
according to the technical constraints of the Digital Resource and renderer. 



NOTE 2 An mx : Play is a render right. 



9.6.12 Print 

Let r be an mx : Print. Then r identifies the act of Print as defined in ISO/IEC 21 000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the SourceOfPrintedResource as defined in ISO/IEC 
21000-6 and, letting z be the Authorization Context Member of that authorization request, x.mxrsourceO shall 
identify the repository that is the PlaceOfPrintingFrom as defined in ISO/IEC 21000-6. 

NOTE 1 An mx : Print identifies the act of deriving a fixed and directly perceivable representation of a Resource. An 
mx; Print refers to the making of a fixed physical representation, such as a hard-copy print of an image or text, that can 
be perceived directly (that is, without any intermediary process) with one or more of the five human senses. 

NOTE 2 An mx ; Print is a render right. 



9.6.13 Reduce 

Let r be an mx : Reduce. Then r identifies the act of Reduce as defined in ISO/IEC 21000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the Reduced Resource as defined in ISO/IEC 21000-6 
and, letting X be the Authorization Context Member of that authorization request, xmx.sourceO shall identify 
the repository that is the PlaceOf Reducing as defined in ISO/IEC 21000-6. 

NOTE An mx: Reduce identifies the act of modifying a Resource by taking away from it. With an mx: Reduce, a 
single Resource is preserved at the end of the process. Changes can include only the removal of existing elements of the 
original Resource. 

9.6.14 Uninstall 

Let r be an mx: uninstall. Then r identifies the act of Uninstall as defined in ISO/IEC 21000-6. 

If r is used as the Right Member of an authorization request, then both the Resource Member of that 
authorization request shall be present and shall identify the UninstallingResource as defined in ISO/IEC 
21000-6 and, letting 2 be the Authorization Context Member of that authorization request XmxisourceO shall 
identify the repository that is the PlaceOf Uninstalling as defined in ISO/IEC 21000-6. 

NOTE An mx: uninstall identifies the act of following the instructions provided by an UninstallingResource as 
defined in ISO/IEC 21000-6. 

9.7 Multimedia extension resources 

9.7.1 DiltemReference 

Let t be an mx: DiltemReference and i be the value of f/mx: identifier. Then t identifies the Digital Item 
identified by i using ISO/IEC 21000-3 less any sub-Digital Items of that Digital Item. 

EXAMPLE 

<mx: diltemRef erence) 

<mx : identifier >urn : acme :mpeg-rel-unleashed</mx: identifier > 

< /mx : diltemRef erence > 
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9.7.2 DIReference 

Let t be an mx : DIReference and i be the value of //rax: identifier. Then t identifies the Container, 
Descriptor, Digital Item, Component, or Fragment identified by i using ISO/IEC 21000-3. 

EXAMPLE 

<mx : diRef erence) 

<mx : identif ier >um : acme : mpeg- rel-unleashed< /rax : identifier > 
< /mx ; diRef erence > 

9.8 Multimedia extension conditions 

9.8.1 Digital Item conditions 

9.8.1.1 DiCriteria 

Let c be an mx: DiCriteria. Let (p, r, t 9 v, 1, L, R) be an authorization request. Let (g, h t e) be an 
authorization story. Let t be the time instant at the start of v. Then c is Satisfied with respect to (p, r, t, v, Z, Z, 
R) and (g, h 9 e) if and only if a new XML document containing JT.mx:didl(c/mx: diRef erence, x) as the root 
element Matches each of the c/r :anXmiPatternAbstract children of c with respect to (p, r, /, v, X, L, R) 
and e. 

EXAMPLE 

<mx : diCriteria> 

<mx : diRef erence > 

<mx : identif ier>urn : acme : mpeg-rel-unleashed< /mx : identif ier > 

< /mx : diRef erence > 

<r : anXralExpression> / /didl : Resource/ @miraeType [ contains { . , "video/rapeg" ) ] </r : anXmlExpressi 

on> 

< /mx : diCrit eria> 

9.8.1.2 DiPartOf 

Let c be an mx : DiPartOf . Let (p, r, /, v, X, L, R) be an authorization request. Let (g, h, e) be an authorization 
story. Let a be the first child of c. Let b be the second child of c. Let r be the time instant at the start of v. 
Then c is Satisfied with respect to (p, r, t, v, E % L, R) and {g, h t e) if and only if X.mxrpartOf (a, b, is true. 

EXAMPLE 
<mx:diPartOf > 

<mx : diRef erence > 

<mx : identif ier >urn : acme : photographs : logo< /mx : identif ier > 
< /mx r diRef erence > 
<rax : diRef erence > 

<mx : identif ier > urn : acme : mpeg-rel -unle ashed < /mx : identif ier > 
< /rax : diRef erence > 
</mx:diPartOf > 

9.8.2 Marking conditions 
9.8.2.1 IsMarked 

Let c be an mx : IsMarked. Let (p, r, t, v, z, L, R) be an authorization request. Let (g, h, e) be an authorization 
story. Let a be the c/r : resource child of c. Let b be the other child of c. Let r be the time instant at the start 
of v. Then c is Satisfied with respect to (p, r, /, v, X, L, R) and fe, h, e) if and only if ^.mxrmarked^, b, t) is true. 

EXAMPLE 

<mx : isMarked> 

<mx : diRef erence) 

<mx : identif ier >urn : acme : photographs : superbow!2 5 < /mx : identif ier > 
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< /mx : diRef erence> 

<acme:acmeWatermark value = "photographer Acme Man w /> 
< /mx : isMarked> 

9.8.2.2 Mark 

Let c be an mx:Mark. Let <p, r, t, v, R) be an authorization request. Let (g, * B e) be an authorization story. 
Let a be the c/r : resource child of c. Let *> be the other child of c. Then c is Satisfied with respect to <p, r, f , v, 
2*, L, K) and (g, fc, e) if and only if Xmx:mark(a, fr) is true. 

EXAMPLE 
<mx : mark) 

<mx : diRef erence> 

<rax : identifier >urn : acme : photographs : superbowl25</mx: identifier > 

< /rax : diRef erence> 

<acroe:acmeWatermark value="photographer=Acme Man*/> 
</mx:mark> 

9.8.3 Security conditions 

9.8.3.1 Destination 

Let c be an mx: Destination. Let (p, r, t, v, r, L, R) be an authorization request. Let (g h, e) be an 
authorization story. Then c is Satisfied with respect to (p, r, t, v, X, L, tf) and (g, A, e) if and only if 
c/r : principal is Equal to X.mxidestinationO- 

EXAMPLE 

<mx:destination> 

<r:keyHoXder licensePartldRef ="dest inationRepos it ory /> 

</mx: destination 

9.8.3.2 Heiper 

Let c be an mx:Heiper. Let (p, r, f, v, JT, L, R) be an authorization request. Let (g, A, e) be an authorization 
story Then c is Satisfied with respect to (p, r, *, v, L, R) and (g, * , e) if and only if, for each r : Principal n 
in 2*.mx:helpers0, either k is Equal to one of the c/r:principai elements or there is a c/mx: wildcard 
element w such that a new XML document containing n as the root element Matches each of the 
iv/r : anXmlPatternAbs tract children of w, if any are present. 

EXAMPLE 
<mx: helper > 

<r:keyHolder licensePartldRef ="acmeMediaPlayer /> 
</mx: helper > 

9.8.3.3 Renderer 

Let c be an mx tenderer. Let (p, r. t, v, Z. L, R) be an authorization request. Let (g, A, e) be an authorization 
story Then c is Satisfied with respect to (p, r, f, v, X, L, *) and (g, h f e) if and only if, for each r : Principal * 
in 2Tnx:renderers(), either * is Equal to one of the c/r:principai elements or there is a c/inx: wildcard 
element w such that a new XML document containing n as the root element Matches each of the 
w>/r:anXmlPatternAbstract children of w, if any are present. 

EXAMPLE 

<mx: render er> 

<r:keyHolder licensePartldRef ="trustedDevice" /> 

</mx: renderer > 
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9.8.3.4 ResourceSignedBy 

Let c be an rax : ResourceSignedBy. Let (p, r, r, v, X, L, R) be an authorization request. Let (g, A, e) be an 
authorization story. Let r be the time instant at the start of v. Then c is Satisfied with respect to (p, r, t t v, T, L, 
R) and (g, h, e) if and only if there exists some dsig : Signature s such that alt of the following are true: 

— Xmx:sigFound(s, t) is true, 

— c/dsig:CanonicalizationMethod is Equal to 
s/dsig : Signedlnf o/dsig : CanonicalizationMethod, 

— c/dsig : SignatureMethod is Equal to 5/dsig : Signedlnf o/dsig : SignatureMethod, 

— there exists some 5/dsig : Signedlnf o/dsig : Reference /such that all of the following are true: 

— c/dsig : Transforms is Equal to //dsig : Transforms (or both are absent), 

— c/dsig : DigestMethod is Equal to //dsig : DigestMethod, and 

— -T.mx:sigRefValid(s,/, c/r: resource, x) is true, and 

— 2*.mx:sigSigValid(.y, c/r : principal, x) is true. 
EXAMPLE 

<mx : resourceSignedBy > 

<dsig: CanonicalizationMethod Algorithm=-http; //www. w3 .org/TR/ 2001 /REC-xml-cl4n- 
20010315V> 

<dslg: SignatureMethod Algorithm="http: //www. w3 .org/2000 /0 9 /xmldsig#rsa-shal w /> 
<mx : diRef erence> 

<mx : identif ier>urn : acme : mpeg-rel-unleashed< /mx : identif ier> 
</mx : diRef erence> 

<dslg: DigestMethod Algorithm="http : //www.w3 .org/2000/09/xmldsig#shal" /> 
<r : keyHolder licensePart IdRef = " acme "/> 
< /mx : resourceSignedBy > 

9.8.3.5 Source 

Let c be an mx: Source. Let (p, r, *, v, Z, L, R) be an authorization request. Let (g, h, e) be an authorization 
story. Then c is Satisfied with respect to (p, r, /, v, X, L, R) and (g, h, e) if and only if c/r : principal is Equal 
to Xmx^ourceO- 

EXAMPLE 
<rox: source > 

<r : keyHolder licensePart IdRef - " sourceReposltory ■ / > 
</mxr source > 

9.8.4 Transaction 

Let c be an mx: Transaction. Let (p, r, /, v, X, L, R) be an authorization request. Let (g, h, e) be an 
authorization story. Let m be c/r : serviceRef erence. Let p be the ordered tuple containing the values of 
the reference-specific parameters determined by m. Then c is Satisfied with respect to (p, r, t, v, X, L, R) and 
(g, h % e) if and only if X.mx:tXA(Wr : serviceDescription, p) is true. 

EXAMPLE 

<mx : transaction) 

<r : serviceRef erence > 

<sx: uddi licensePar t IdRef ="uddiDescript ion" /> 
<r :serviceParameters> 
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<r:datum> 

<mx : diRef erence) 

<mx: identifier >urn : acme :mpeg-rel-unleashed</mx: identifier > 
< /mx : diRef erence > 
</r:datum> 
</r : serviceParameters> 
< /r : serviceRef erence > 
< /mx : t ran s ac t ion > 

9.8.5 Resource attribute conditions 

9.8.5.1 ProhibitedAttributeChanges 

Let c be an mx: ProhibitedAttributeChanges. Let (p, r, t, v, 2 9 L y R) be an authorization request. Let {g, 
h f e)be an authorization story. Then c is Satisfied with respect to {p, r, t, v, z, Z,, R) and fe, h, e) if and only if 
for each resource attribute set definition element child s of c there is no resource attribute that is both a 
member of xmxrrACO and a member of the set identified by s. c may have no resource attribute set definition 
element children even if it also has no r:licensePartidRef or rrvarRef attribute; in this case c is 
Satisfied with respect to (p, r, t, v, Z 9 L, R) and (g, h, e). 

EXAMPLE 

<mx : ProhibitedAttributeChanges > 

<mx : set definition^ "urn : osmaker : f ileProperties " / > 
< /mx : ProhibitedAttributeChanges > 

9.8.5.2 RequiredAttributeChanges 

Let c be an mx: RequiredAttributeChanges. Let (p, r, /, v, 2*, L, R) be an authorization request. Let (g, h 9 
e) be an authorization story. Then c is Satisfied with respect to (p, r, t, v, x 9 L, R) and (g, h t e) if and only if for 
each resource attribute set definition element child s of c there is no resource attribute that is both a member 
of the set identified by s and not a member of XmxrrACO. c may have no resource attribute set definition 
element children even if it also has no r:licensePartidRef or r;varRef attribute; in this case c is 
Satisfied with respect to (p, r, /, v, £, L, R) and (g, h, e). 

EXAMPLE 

<mx : requiredAt tributeChanges > 

<rax : set definitions "urn : osmaker : f ileProperties ■ / > 
</mx: requiredAt tributeChanges > 

9.9 Multimedia extensions patterns 

No other patterns are defined in the Multimedia Extension Namespace. 

9.10 Multimedia extension delegation constraints 

No other delegation constraints are defined in the Multimedia Extension Namespace. 

9.11 Multimedia extension trust roots 

No other trust roots are defined in the Multimedia Extension Namespace. 

9.12 Multimedia extension service descriptions 

No other service descriptions are defined in the Multimedia Extension Namespace. 
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9.13 Multimedia extension properties 

No other properties are defined in the Multimedia Extension Namespace. 

9.14 Multimedia extension name properties 

No other name properties are defined in the Multimedia Extension Namespace. 
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Annex A 

(normative) 



W3C XML Schemas 



A.1 General 

This Annex contains a listing of the three schemas (XMLSCHEMA) that define the XML syntax of the types 
and elements defined throughout this part of ISO/IEC 21000. 



A.2 Schema for the Core Namespace 

<?xml version="1.0" encodings "UTF- 8 "?> 

<xsd : schema targetNamespace="urn:mpeg:mpeg21 : 2003 : 01-REL-R-NS" 

xmlns : r="urn :mpeg :mpeg21 : 2003 : 01-REL-R-NS" 

xmlns:enc="http://www.w3.org/2001/04/xmlenc#" 

xmlns : dsig="http : //www. w3 . org/2000/09/xmldsig# " 

xmlns ; xsd= "ht tp : / /www . w3 . org/ 2001 /XMLSchema" 

xmln s:sccns=" urn : uddi - or g : s chemaCent r icC 14N:2002-07-10" 

elementFormDef ault= "qualified" attributeFormDef ault= n unqualified" > 

<xsd : import namespace= " htt p : / /www . w3 . or g/XML / 1998 /namespace " 
schemaLocat ion= " ht tp ; / /www . w3 . org/ 20 0 1 /xml . xsd" / > 

<xsd : import namespace= "http : //www . w3 . org/2001/04 /xmlenc# " 
schemaLocation="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc- 

schema . xsd" / > 

<xsd: import namespace="http: //www.w3 .org/2000/09/xmldsig#" 
schemaLocation-"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core- 

schema . xsd" / > 

<xsd: import namespace= " urn : uddi - org : schemaCent r icC 14N:2002-07-10" 
schemaLocation="http: //www. uddi.org/schema/SchemaCentricCanonicalization. xsd" /> 

< ! Elements 

<xsd:element name="allConditions" type="r :AllConditions" 
substitutionGroup="r: condition" /> 

<xsd:element name="allPrincipals" type="r : AllPrincipals" 
substitutionGroup= "r : principal" / > 

<xsd:element name ="anXmlExpress ion" type- "r :AnXmlExpress ion" 
substitutionGroup="r :anXmlPatternAbstract"/> 

<xsd:element name="anXmlPatternAbs tract" type="r :AnXmlP at ternAbs tract" 
subs t itut ionGroup= " r : resource" / > 

<xsd:element name= "condition" type="r: Condition" 
subs t itut ionGroup= " r : licensePart " / > 

<xsd : element name= "conditionlncremental" type= "r : Condi t ion Incremental" 
subst itut ionGroup= " r : dcCons traint " / > 

<xsd:element name ="conditionPat tern" type="r :ConditionPattern"/> 

<xsd : element name= " condit ionPat ternAbs tract " type= " r : Condit ionPatternAbs tract " 
substitutionGroup«"r :anXmlPat ternAbs tract "/> 

<xsd: element name=" datum" type="r: Datum" /> 

<xsd : element name= "condit ionUnchanged" type* "r : Condit ionUnchanged" 
subst itutionGroup= "r : dcCons traint " / > 

<xsd: element name= "dcCons traint " type="r: DcCons traint" 
subst it utionGroup= " r : licensePart " / > 

<xsd : element name- "delegationControl" substitutionGroup= "r : licensePart " > 



<xsd : complexType> 
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<xsd : complexContent > 

<xsd : extension base- "r : LicensePart n > 
<xsd: sequence) 

<xsd: element ref = n r : dcConstraint " minOccurs="0" 



maxOccurs = " unbounded" / > 

< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexContent > 
</xsd:complexType> 
< /xsd : element > 

<xsd : element name= B depthCons traint n type= B r : DepthCons traint " 
substitutionGroup= w r : dcConstraint n /> 

<xsd : element name= " digit alResource " type= "r : Digit alResource n 
substitutionGroup= "r : resource" / > 

<xsd: element name ="exerciseMechan ism" type="r : ExerciseMechanism" 
substitutionGroup="r: condition"/) 

<xsd : element name= "exist sRight " type= "r : Exist sRight " 
subs ti tut ionGroup= "r : condition" / > 

<xsd : element name= " f orAll " block= " fall " subs t itut ionGroup= " r : licensePart " 
final="#all"> 

<xsd : complexType) 

<xsd : complexContent > 

<xsd : extension base= "r : LicensePart " > 
<xsd : sequence) 

<xsd : element ref = "r : anXmlPat t ernAbs tract " minOccurs= " 0 " 
maxOccurs = "unbounded" / > 

< /xsd: sequence) 

<xsd : attribute name= "varName " type="r : Var iableName " / > 
< /xsd : extension) 
< /xsd : complexContent ) 
< / x s d : c omp 1 exType > 
< /xsd : element ) 

<xsd:element name="±Tulf iller" type="r :Fulf iller" 
substitutionGroup= "recondition"/) 

<xsd : element name= " grant " type= " r : Grant " subst itut ionGroup= " r : resource " / > 
<xsd:element name=" grant Group" type="r: Grant Group" 
subst itut ionGroup= " r : resource " / > 

<xsd: element name="grantGroupPattern" type="r :GrantGroupPattern" 
subst itut ionGroup= " r : resourcePatt ernAbs tract " / ) 

<xsd:element name= " grant Pat tern " type="r: Grant Pat tern" 
subst itut ionGroup="r : resourcePatt ernAbstract " / ) 

<xsd:element name="issue" block="#all" substitutionGroup="r : right" 
final="#all") 

<xsd : complexType) 

<xsd: complexContent > 

<xsd: extension base="r : Right "/> 
< /xsd : complexContent ) 
< /xsd : complexType) 
< /xsd: element) 

<xsd: element name=" issuer" type="r: Issuer" /) 
<xsd:element name="keyHolder" type="r :KeyHolder" 
subst itut ionGroup= " r : principal " / > 

<xsd: element name=" license" type="r : License" /> 

<xsd : element name= " licenseGroup" type= " r : LicenseGroup" / > 

<xsd : element name= " licensePart " type= "r : LicensePart " / ) 

<xsd : element name= " obtain " type= "r : Obtain " subst itut ionGroup= "r : right " / > 
<xsd : element name= "patternFromLicensePart " type= "r : PatternFromLicensePart " 

subs t itut ionGroup= " r : anXmlPatt ernAbstract " / > 

<xsd:element name="possessProperty" type="r :PossessProperty" 

subst itut ionGroup= "r : right " / > 
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<xsd: element name="prerequisiteRight " type="r : PrerequisiteRight" 
subs t i tut ionGr oup= " r : condition " / ) 

<xsd: element name = "principal" type="r: Principal" 
subs t itut ionGroup- "r : resource" / > 

<xsd:element name="principalPattern" type="r : PrincipalPattern"/> 

<xsd : element name= "principalPatternAbs tract " type= " r : PrincipalPat ternAbs tract " 
subs t itut ionGroup= " r : resourcePat ternAbs tract " / > 

<xsd: element name="propertyAbs tract" type="r: Proper tyAbstract" 
subs t itut ionGroup= " r : resource " / > 

<xsd: element name="propertyPossessor" type="r :PropertyPossessor" 
subs t itutionGroup= " r : principalPatternAbs tract " / > 

<xsd:element name=" re source" type="r: Resource" 
substitutionGroup="r: licensePart" /> 

<xsd : element name= "resourcePat tern" type= "r : ResourcePat tern" /> 

<xsd : element name= "resourcePat ternAbs tract " type= " r : ResourcePatternAbstract " 
substitutionGroup="r:anXmlPatternAbstract"/> 

<xsd: element name = "revocable" type="r: Revocable" 
substitutionGroup="r: resource" /> 

<xsd : element name- "revocat ionFreshnes s " type= "r : RevocationFreshness " 
substitutionGroup="r: condition" /> 

<xsd:element name = "revoke" type="r: Revoke" substitutionGroup="r :right V) 

<xsd:element name="riglit" type="r: Right" substitutionGroup="r : licensePart" /> 

<xsd: element name=" right Pat tern" type="r :RightPattern"/> 

<xsd : element name= " r ight Pat ternAbs tract " type= "r : RightPat ternAbs tract " 
subst itut ionGroup= "r : anXmlPat ternAbs tract " / > 

<xsd:element name="serviceDescription" type="r : ServiceDe script ion" 
substitutionGroup= "r : licensePart " / > 

<xsd : element name= " serviceRef erence " type= " r : ServiceRef erence " 
subs t itutionGroup= "r : resource " / > 

<xsd: element name="toConstraint" type="r :ToConstraint " 
subs t itut ionGroup= "r : dcConstraint " / > 

<xsd:element name="trustedRootGrants" type="r :TrustedRoot Grants" 
subs t itut ionGroup- "r : trustRoot " / > 

<xsd:element name="trustedRoot Issuers" type="r :TrustedRoot Issuers" 
subs t itut ionGroup* "r : trustRoot " / > 

<xsd: element name=" trustRoot" type="rs TrustRoot" 
substitutionGroup="r ; licensePart" /> 

<xsd:element name="validitylnterval" type="r rValiditylnterval" 
subst itut ionGroup= "r : condition " / > 

< I --Complex Types- -> 

<xsd : complexType name= " AllConditions " > 
<xsd : complexCont ent > 

<xsd : extension base= " r : Condi t ion" > 
<xsd: sequence) 

<xsd: element ref="r: condition" minOccurs="0" 
maxOccurs- " unbounded" / > 

</xsd: sequence > 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd : complexType> 

<xsd : complexType name= " AllPrincipals " > 
<xsd: complexCont ent > 

< xsd : extension base= " r : Principal " > 
<xsd : sequence) 

<xsd: element ref="r: principal" minOccurs="0" 
maxOccur s = " unbounded " / > 

< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd : complexType) 
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<xsd:complexType name= n AnXralExpres s ion " mixed="true B 
sccns : embeddedLangAttribute= "r : lang" > 

<xsd:complexContent mixed= "true n > 

<xsd : extension base= n r: AnXmlPatternAbs tract " > 
<xsd: attribute name="lang" type="xsd: anyURI" 
default«"http://www.w3.org/TR/1999/REC-xpath-19991116"/> 
< /xsd : ext ens ion > 
< /xsd : complexCont ent > 
< /xsd : complexType> 

<xsd ; complexType name= "AnXmlPatternAbs tract n > 

<xsd : complexCont ent > 

<xsd : extension base="r : Resource" /> 

< /xsd : complexContent > 
< /xsd : complexType > 

<xsd: complexType name= ■ Condition a > 

<xsd: complexCont ent > 

<xsd : extension base= "r : LicensePart " / > 

< /xsd : complexContent > 
< /xsd : complexType > 

<xsd: complexType name="ConditionIncremental" > 

<xsd : complexContent > 

<xsd : extension base= " r : DcCons train t " / > 

< /xsd : complexContent > 
</xsd:complexType> 

<xsd: complexType name= " Condi t ionPat t ern " > 

<xsd: choice minOccurs="0" maxOccurs= "unbounded" > 
< xsd: element ref ="r : anXmlExpression" /> 
<xsd: element ref ="r : conditionPatternAbstract " / > 
< /xsd : choice > 
< /xsd : complexType> 

<xsd : complexType name= "ConditionPatternAbstract " > 
<xsd : complexContent > 

<xsd : extension base= "r : AnXmlPatternAbs tract " / > 
< /xsd : complexContent > 
< /xsd : complexType > 
<xsd: complexType name = "Datum" > 
<xsd : complexContent > 

< xsd : extension base = " r : LicensePart " > 
<xsd: sequence minOccurs="0"> 

<xsd:any namespace="##any" processContents="lax"/> 
< /xsd: sequence > 
< /xsd : extension > 
< /xsd : complexContent > 
< /xsd : complexType> 

<xsd : complexType name= " Condi tionUnchanged" > 

<xsd : complexContent > 

<xsd: extension base="r :DcConstraint"/> 

< /xsd : complexContent > 
< /xsd : complexType > 

<xsd : complexType name- "DcCons traint " > 

<xsd : complexContent > 

<xsd: extension base="r : LicensePart" /> 

< /xsd : complexContent > 
</xsd:complexType> 

<xsd : complexType name="DepthConstraint " > 
<xsd : complexContent > 

<xsd : extension base= "r : DcConstraint " > 
<xsd: sequence minOccurs="0 n > 

<xsd: element name= "count" type="xsd:int"/> 
< /xsd : sequence) 
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< /xsd : extension> 
< /xsd : complexCont ent > 
< /xsd : complexType> 

<xsd : complexType name- "Digit alResource" > 
<xsd : complexCont ent > 

<xsd : extension base= " r : Resource " > 
<xsd; choice minOccurs= n 0 " > 

<xsd : element name = "nonsecure Indirect " 
type= "r : NonSecureRef erence " / > 

<xsd : element name= " securelndirect " type= " dsig : Ref erenceType " / > 
<xsd:element name= "binary" type="xsd: base64Binary"/> 
<xsd: element name= " anXml " > 

<xsd : complexType mixed= " true " > 
<xsd: sequence > 

<xsd:any namespace= " ##any" processContents="lax" 
minOccur s = " 0 " maxOccur s = " unbounded " / > 

< /xsd : sequence> 
< /xsd : complexType > 
< /xsd : element > 

<xsd : any namespace= " ##other " processContent s= " lax" / > 
< /xsd: choice > 
< /xsd: extension > 
< /xsd: complexCont ent > 
< /xsd : complexType > 

<xsd : complexType name= " Encrypt edCon tent " > 

<xsd: complexContent> 

<xsd : extension base- " enc : Encrypt edDataType " / > 

< /xsd : complexCont ent > 
< /xsd : complexType > 

<xsd : complexType name= "ExerciseMechanism" > 
< xsd : complexCont en t > 

<xsd : extension base= "r : Condition" > 
<xsd: choice minOccurs="0"> 

<xsd : element name- " exerciseService " > 
<xsd : complexType > 
<xsd : sequence> 

<xsd : element ref = " r : serviceRef erence " / > 
< /xsd : sequence > 
< /xsd : complexType > 
< /xsd : element > 

<xsd:any namespace="##other" processContents="lax"/> 
</xsd:choice> 
< /xsd : extension> 
< /xsd : complexCont ent > 
< /xsd : complexType > 

<xsd : complexType name= " Exist sRight " > 
<xsd : complexCont ent > 

<xsd : extension base= "r : Condition" > 
<xsd: sequence minOccur s= "0" > 
<xsd:choice> 

<xsd: element ref ="r: grant "/> 
<xsd : element ref = " r : grantGroup " / > 
</xsd:choice> 

<xsd: element ref ="r : trustRoot " minOccurs="0 " /> 
</xsd:sequence> 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd : complexType > 

<xsd: complexType name="Fulf iller" > 
<xsd : complexCont ent > 
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<xsd : extension base= "r : Condition" > 
<xsd: sequence minOccurs="0" > 

<xsd : element ref = " r : principal n / > 
</xsd:sequence> 
< /xsd : extension > 
< /xsd : complexCont ent > 
< / x s d : c ompl exType > 
<xsd : complexType name= "Grant " > 
<xsd : complexCont ent > 

<xsd z extension base= " r : Resource " > 
<xsd: choice minOccurs="0"> 



<xsd : sequence > 

<xsd: element ref ="r : f orAll" minOccurs="0" 



<xsd: element ref ="r :delegationControl" minOccurs="0"/> 
<xsd: element ref ="r: principal" minOccurs="0"/> 
<xsd: element ref ="r: right "/> 

<xsd; element ref ="r: resource" minOccurs="0"/> 
<xsd:element ref ="r :condition" minOccurs="0 n /> 
< /xsd : sequence > 

<xsd : element name= " encryptedGrant " type= " r : EncryptedCont ent "/> 



</xsd:choice> 
< /xsd : extension > 
< /xsd : complexCont en t > 
< /xsd : complexType > 

<xsd : complexType name =" Grant Group "> 
<xsd : complexCont ent > 

<xsd : extension base= " r : Resource " > 
<xsd: choice minOccurs="0"> 



<xsd:sequence> 

<xsd:element ref = n r : f orAll" minOccurs="0" 



<xsd: element ref ="r : delegationControl" minOccurs="0"/> 
<xsd: element ref ="r: principal" minOccurs="0"/> 
<xsd:element ref ="r :condition" minOccurs="0" /> 
< xs d : choice maxOccur s = " unbounded p > 

<xsd: element ref ="r: grant "/> 

<xsd: element ref ="r: gran t Group" /> 
</xsd:choice> 
< /xsd : sequence > 

<xsd : element name= " encryptedGrant Group" 



type= "r : Encrypt edCon tent " / > 
</xsd:choice> 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd : complexType > 

<xsd: complexType name= "GrantGroupPattern" > 
<xsd : complexContent > 

<xsd : extension base= "r : Re sourcePatternAbs tract " > 
<xsd: sequence minOccurs="0" > 



<xsd: choice minOccurs="0" > 

<xsd: element ref ="r: principal" /> 

<xsd : element ref = " r : principalPat t ern " / > 

</xsd:choice> 

<xsd: choice minOccurs="0" > 

<xsd: element ref ="r: condition" /> 

<xsd : element ref = "r : conditionPattern" / > 

< /xsd : choice) 

<xsd : choice maxOccur s= "unbounded" > 
<xsd:choice> 



maxOccur s= "unbounded" / > 



maxOccur s= "unbounded" / > 
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<xsd: element ref ="r: grant" /> 

<xsd : element ref= " r : grant Pat tern " / > 
< /xsd : choice> 
<xsd:choice> 

<xsd : element r ef - n r : grantGroup " / > 

< xs d : element r ef = " r : gr an t Gr oupP at t ern " / ) 
</xsd:choice> 
</xsd:choice> 

<xsd: element name="wholeGrantGroupExpression" 
type="r:AnXmlExpression" minOccurs= n 0" maxOccurs= "unbounded" /> 
</xsd:sequence> 
< /xsd : extension> 
< /xsd : complexCont ent > 
</xsd:complexType> 

<xsd:complexType name = " Grant Pat t ern "> 
<xsd : complexCont ent > 

<xsd : extension base= "r : ResourcePatternAbstract " > 
<xsd: sequence minOccurs="0" > 
<xsd: choice minOccurs="0" > 

<xsd: element ref ="r: principal"/) 
<xsd : element ref - " r : principalPatt ern" / > 
< /xsd: choice > 
<xsd:choice> 

<xsd: element ref-"r : right "/> 
<xsd : element ref = " r : rightPat tern " / > 
</xsd:choice> 

<xsd: choice minOccurs="0" > 

<xsd: element ref ="r: resource" /> 

<xsd : element ref = " r : resourcePat t ern " / > 
</xsd:choice> 

<xsd: choice minOccurs="0"> 

<xsd: element ref ="r: condition" /> 

<xsd: element ref = "r : conditionPattern" /> 
</xsd:choice> 

<xsd: element name="wholeGrantExpression" type = n r:AnXmlExpress ion" 
minOccur s = " 0 " maxOccurs = " unbounded " / > 
< /xsd : sequence > 
< /xsd : extension> 
< /xsd : complexCont ent > 
< /xsd : complexType> 

<xsd : complexType name=" Inventory") 
<xsd : sequence> 

<xsd: choice minOccurs="0" maxOccurs= " unbounded" > 

<xsd : element ref = " r : licensePart " / > 
</xsd:choice> 
< /xsd : sequence) 
< /xsd : complexType> 
<xsd: complexType name=" Issuer" > 
<xsd: sequence) 

<xsd:choice minOccurs="0" > 

<xsd : element ref = " dsig : Signature " / > 
<xsd:element ref = n r: principal"/) 
< /xsd : choice) 

<xsd:element name=" details" type="r : IssuerDetails" minOccurs="0"/) 
< /xsd : sequence) 
< /xsd : complexType) 

<xsd : complexType name= " I ssuerDet ails " > 
<xsd : sequence) 

<xsd: element name="timeOf Issue" type="xsd:dateTime" minOccurs="0"/) 



© ISO/IEC 2003 — All rights reserved 



69 



ISO/IEC FDIS 21000-5:2003(1 



<xsd : element name= "revocationMechanism" type="r : Revocat ionMechanism" 
minOccur s = "0" maxOccur s = " unbounded " / > 
< /xsd : sequence > 
< /xsd : complexType> 

<xsd:complexType name="KeyHolder"> 
<xsd : complexContent > 

<xsd : extension base= "r : Principal n > 
<xsd: sequence minOccurs= B 0 n > 

<xsd: element name= n info n type="dsig:KeyInf oType"/) 
< /xsd: sequence > 
< /xsd : extension) 
< /xsd : complexContent > 
< /xsd : complexType> 
<xsd : complexType name= w License " > 
<xsd: choice > 

<xsd: sequence > 

<xsd: element name="title" type="r : Linguist icSt ring" minOccurs= "0" 
maxOccur s= "unbounded" / > 

<xsd ; element name = B inventory" type="r: Inventory" minOccurs-"0" /> 
<xsd: choice minOccurs="0" maxOccurs= " unbounded " > 

<xsd: element ref ="r: grant"/) 

<xsd : element ref="r: grant Group" / > 
< /xsd : choice> 

<xsd: element ref ="r: issuer" minOccurs«"0" maxOccur s = " unbounded " / > 
<xsd: element name=" other Info" minOccurs="0" > 
<xsd : complexType > 
<xsd: sequence) 

<xsd:any namespace="##any" processContents="lax" 
maxOccur s= "unbounded" / > 

< /xsd : sequence) 
< /xsd : complexType) 
< /xsd : element ) 
< /xsd : sequence) 

<xsd : element name= " encrypt edLicense " type= "r : Encrypt edContent " / > 
< /xsd: choice) 

<xsd: attribute name="licenseld" type="xsd: anyURI" use=" optional"/) 
<xsd:anyAt tribute namespace="##other" processContents="lax"/) 
< /xsd : complexType) 

<xsd : complexType name= " LicenseGroup" > 
<xsd : sequence) 

<xsd:element ref ="r : license" minOccurs="0" maxOccur s= "unbounded"/) 
< /xsd : sequence) 
< /xsd : complexType > 

<xsd: complexType name= "LicensePart") 

<xsd: attribute name=" licensePart Id" type="r :LicensePartId" use="optional"/) 
<xsd : attribute name= " licensePart IdRef " type= " r : LicensePart Id" 
use="optional"/> 

<xsd: attribute name= "varRef " type="r :VariableName" use= "optional" /> 
< /xsd : complexType) 

<xsd: complexType name="LinguisticString" mixed=" true" > 
<xsd: complexContent mixed="true"> 

<xsd : restriction base= " xsd : anyType " > 
<xsd : sequence) 

<xsd:any processContents="lax n minOccurs="0" 
maxOccur s = " unbounded " / > 

< /xsd: sequence) 

<xsd: attribute ref ="xml : lang" /) 
< /xsd : restriction) 
< /xsd : complexContent > 
< /xsd : complexType) 
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<xsd: complexType name = " NonSecureRef erence " > 
<xsd : sequence) 

<xsd: element ref = " dsig : Transforms n minOccurs="0"/) 
</xsd: sequence) 

<xsd: attribute name="Id B type= n xsd: ID" use= "optional" /> 
<xsd: attribute name="URI" type="xsd: anyURI" use=" optional"/) 
<xsd: attribute name="Type" type="xsd:anyURI" use="optional"/> 

< /xsd : complexType) 

<xsd: complexType name= "Obtain" ) 
<xsd : complexContent > 

<xsd: extension base="r : Right " /> 
< /xsd : complexContent ) 

< /xsd : complexType) 

<xsd : complexType name= "PatternFromLicensePart " > 
<xsd z complexContent ) 

<xsd ; extension base= "r : AnXmlPatt ernAbs tract " > 
<xsd: sequence minOccurs="0" ) 

<xsd ; element ref = " r : licensePart " / > 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexContent ) 
< /xsd : complexType) 

<xsd: complexType name= "PossessProperty " > 

<xsd : complexContent > 

<xsd: extension base="r: Right"/) 

< /xsd : complexContent ) 
< /xsd : complexType ) 

<xsd : complexType name= ■ PrerequisiteRight " ) 
<xsd : complexContent > 

<xsd : extension base= " r : Condition" > 
<xsd: sequence minOccurs="0"> 

<xsd: element ref ="r: principal" minOccurs="0" /> 
<xsd: element ref ="r: right " /) 

<xsd: element ref ="r: resource" minOccurs=" 0"/) 
<xsd:element ref ="r : trustRoot" minOccurs="0" /> 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexContent ) 
< /xsd : complexType) 

<xsd: complexType name= " Principal " ) 

<xsd : complexContent ) 

<xsd : extension base= " r : Resource " / > 

< /xsd : complexContent > 
< /xsd : complexType) 

<xsd : complexType name- " PrincipalPat t ern " ) 

<xsd: choice rainOccurs-"0" maxOccurs= "unbounded") 
<xsd : element ref = "r : anXmlExpression" / > 
<xsd : element ref = "r : principalPatt ernAbs tract " / ) 
< /xsd : choice) 
< /xsd : complexType) 

<xsd : complexType name= n PrincipalPat ternAbstract " ) 

<xsd : complexContent > 

<xsd : extension base= " r : Re sourcePat ternAbstract " / > 

< /xsd : complexContent > 
< /xsd : complexType > 

<xsd : complexType name- " PropertyAbs tract " > 

<xsd : complexContent > 

<xsd : extension base= "r : Resource" / ) 

< /xsd : complexContent > 
</xsd: complexType) 
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<xsd : complexType name= "PropertyPossessor " > 
<xsd:complexContent> 

<xsd ; extension base= "r : PrincipalPat ternAbstract " > 
<xsd: sequence minOccurs="0"> 

<xsd : element ref = n r : propertyAbs tract " / > 
<xsd: element ref = B r : trustRoot " minOccurs="0"/> 
< /xsd: sequence) 
</xsd: extension > 
< /xsd : complexCont ent > 
< /xsd : complexType > 

<xsd: complexType name- "Resource " > 

<xsd : complexContent > 

<xsd : extension base= " r : LicensePart n / > 

< /xsd : complexContent > 
</xsd : complexType > 

<xsd : complexType name= "ResourcePattern n > 

<xsd: choice minOccurs- n 0 n maxOccurs= "unbounded" > 
<xsd: element ref = "r : anXmlExpression" / > 
<xsd : element ref - " r : resourcePat ternAbstract " / ) 
</xsd:choice> 
</xsd:complexType> 

<xsd : complexType name= " ResourcePat ternAbstract " > 

<xsd : complexContent > 

<xsd : extension base- "r : AnXmlPat ternAbstract " / ) 

< /xsd : complexContent > 
< /xsd : complexType > 

<xsd : complexType name= "Revocable n > 
<xsd : complexContent > 

<xsd : extension base= " r : Resource" > 
<xsd: choice minOccurs-"0"> 

<xsd : element ref = "dsig : Si gnature Value" /> 
<xsd : element ref = " dsig : Reference " / > 
<xsd : sequence) 

<xsd; element name="licenseld" type="xsd: anyURI"/) 
<xsd: element ref ="r: principal"/) 
< /xsd: sequence > 
</xsd:choice> 
< /xsd : extension) 
< /xsd : complexContent > 
< /xsd : complexType) 

<xsd : complexType name= "RevocationFreshness " > 
<xsd : complexContent) 

<xsd: extension base=*"r : Condition" ) 
<xsd: sequence minOccurs- "0" > 

< xsd : element name- " pr iorToStart " type= "xsd : durat ion " / > 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexContent > 
< / x s d : c omp lexType > 

<xsd : complexType name= "RevocationMechanism" > 
<xsd: choice) 

<xsd: element name= " revocat ionService " ) 
<xsd : complexType) 
<xsd: sequence) 

<xsd : element ref = " r : serviceRef erence " / ) 
< /xsd ; sequence) 
< /xsd : complexType) 
< /xsd : element > 

<xsd:any namespace="##other " processCont ent s= " lax " / > 
< /xsd: choice) 
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< /xsd : complexType> 

<xsd : complexType name = " Revoke " > 

<xsd : complexCont ent > 

<xsd : extension base-"r: Right "/> 

< /xsd : complexCont ent > 
< /xsd : complexType > 
<xsd: complexType name= "Right "> 

<xsd:complexContent> 

<xsd : extension base= " r : LicensePart " / > 

< /xsd : complexCont ent > 
< /xsd : complexType > 

<xsd: complexType name=" Right Pat tern" > 

<xsd: choice minOccurs="0" maxOccurs - "unbounded" > 
<xsd: element ref = " r : anXmlExpres sion " / > 
<xsd : element ref = "r : right Pat ternAbs tract " / > 
< /xsd: choice > 
< /xsd : complexType > 

<xsd : complexType name= "Right Pat ternAbs tract " > 

<xsd : complexCont ent > 

<xsd : extension base= "r : AnXmlPat ternAbs tract " / > 

< /xsd : complexContent > 
< /xsd : complexType > 

<xsd : complexType name- "ServiceDe script ion" > 

<xsd : complexContent > 

<xsd : extension base= " r : LicensePart " / > 

< /xsd : complexContent > 
< /xsd : complexType> 

<xsd : complexType name= " ServiceRef erence " > 
<xsd : complexCont ent > 

<xsd: extension base="r: Resource" > 
<xsd: sequence minOccurs="0" > 

<xsd : element ref = " r : serviceDescr ipt ion " / > 
<xsd: element name= " serviceParameters " minOccurs-"0"> 
<xsd : complexType > 

<xsd: sequence minOccurs="0" maxOccurs=" unbounded "> 
<xsd: element ref ="r: datum" /> 

<xsd : element name= " transforms " type= " dsig : Trans forms Type " 

minOccur s = "0"/> 

< /xsd : sequence > 
< /xsd : complexType > 
< /xsd : element > 
< /xsd : sequence> 
< /xsd : extension > 
< /xsd : complexContent > 
< /xsd : complexType > 

<xsd: complexType name="ToConstraint"> 
<xsd : complexContent > 

<xsd : extension base= " r : DcConstraint " > 
<xsd: sequence > 

<xsd:element ref = n r : for All" minOccurs="0" maxOccurs= "unbounded" /> 
<xsd: element ref ="r: principal" minOccurs="0" 
maxOccurs = " unbounded " / > 

< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexContent > 
< /xsd : complexType> 

<xsd : complexType name= "Trust edRootGrant s " > 
<xsd: complexCont ent > 

<xsd : extension base= " r : TrustRoot " > 
<xsd: sequence minOccurs="0" > 
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<xsd : element ref= B r: grant " maxOccurs= "unbounded" / > 
</xsd: sequence> 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd : complexType > 

<xsd : complexType name = " Trus t edRoo 1 1 s suer s " > 
<xsd : complexCont ent > 

<xsd : extension base- n r : TrustRoot " > 
<xsd: sequence minOccurs="0 B > 

<xsd: element ref = "r : principal" maxOccurs= "unbounded" / > 
< /xsd : sequence) 
< /xsd: extension) 
< /xsd : complexCont ent > 
< /xsd : complexType) 

<xsd : complexType name = "TrustRoot " ) 

<xsd : complexCont ent ) 

<xsd : extension base="r: LicensePart " / > 

< /xsd : complexCont ent ) 
< /xsd : complexType ) 

<xsd : complexType name= "Validity Interval " ) 
<xsd : complexCont ent ) 

<xsd : extension base= " r : Condition " > 
<xsd : sequence) 

<xsd: element narae="notBef ore" type="xsd:dateTime" minOccurs="0"/) 
<xsd: element name="notAfter" type="xsd: dateTime" minOccurs="0"/> 
< /xsd s sequence) 
< /xsd : extension) 
< /xsd : complexCont ent ) 
< /xsd : complexType) 
<!-- Simple Types--) 

<xsd : simpleType name= "LicensePart Id" > 

<xsd : restriction base= "xsd : NCName " / > 
</xsd: simpleType) 

<xsd : simpleType name= " VariableName" ) 

<xsd : restriction base= " xsd : NCName " / ) 
</xsd: simpleType) 
< /xsd : schema) 



A.3 Schema for the Standard Extension Namespace 

<?xml version^ "1.0" encoding="UTF-8"?> 

<xsd: schema t ar get Name space = "urn :mpeg:mpeg21 : 2003 : 01-REL-SX-NS" 
xmlns : sx="urn:mpeg:mpeg21 : 2003 : 01-REL-SX-NS" 
xmlns : r="urn :mpeg :mpeg21 : 2003 : 01-REL-R-NS" 
xmlns :dsig= "http://www.w3.Org/2000/09/xmldsig#" 
xmlns : xsd= " ht tp : / /www . w3 . org/ 20 0 1 /XMLSchema " 

elementFormDefault=" qualified" attributeFormDef ault=" unqualified " ) 

<xsd : import namespace- "urn :mpeg :mpeg21 : 2003 : 01-REL-R-NS" schemaLocation="rel- 
r.xsd"/) 

<xsd:import namespace="http: //www.w3 . org/2000/09/xmldsig#" 

schemaLocation="http: //www. w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core- 
schema . xsd" / ) 

<!-- Elements --) 

<xsd : element name- " anonymous St at eService " type= " sx : Anonymous St at eService " 
subst itut ionGroup= "r : serviceDescript ion " / ) 

<xsd : element name= "callForCondition" type= " sx : CallForCondition" 
subst itut ionGroup= "r : condition" / ) 

<xsd: element name="commonName" type= "sx :CommonName" 
subst itut ionGroup= " sx : name" / ) 
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<xsd;element name = n dns Name" type= n sx : DnsName n substitut ionGroup= n sx : name" / > 

<xsd: element name= " emailName " type= " sx : EmailName" 
subs t itut ionGroup= " sx : name " / > 

<xsd: element name= " exerciseLimi t " type="sx:ExerciseLimit " 
subst itut ionGroup= "r ; condition" / > 

<xsd: element name="f eeFlat " type= " sx : FeeFlat " 
subs titutionGroup= "r : condition" / > 

<xsd: element name="f eeMetered" type="sx:FeeMetered" 
substitut ionGroup= " r ; condition" / > 

<xsd: element name= " f eePer Interval" type ="sx:FeePer Interval" 
sub s t i t u t ionGr oup = "r:condition"/> 

<xsd:element name="f eePerUse" type="sx:FeePerUse" 
subst itutionGroup= " r : condition" / > 

<xsd: element name="f eePerUsePrePay" type="sx:FeePerUsePrePay" 
subs t itut ionGroup= "r : condition" / > 

<xsd:element name=" license I dPat tern" type="sx:LicenseIdPattern" 
subs t itut ionGroup= " r : anXmlPatternAbs tract " / > 

<xsd: element name="name" type="sx:Name" 
substitutionGroup="r:propertyAbstract"/> 

<xsd: element name="propertyUri" type="sx:PropertyUri" 
subs t itut ionGr oup= " r : proper tyAbs tract " / > 

<xsd: element name =" rate" type="sx:Rate" subst itut ionGroup="r : licensePart"/> 

<xsd:element name=" right Uri" type= "sx: Right Uri" subst itutionGroup="r: right"/ > 

<xsd: element name= " seekApproval " type="sx: SeekApproval" 
substitutionGroup= "r : condition" / > 

<xsd:element name="stateDistinguisher" block="#all" 
substitut ionGroup= " r : licensePart " f inal= " #all" > 
<xsd : complexType mixed= " true " > 

<xsd:complexContent mixed=" true" > 

<xsd : extension base= " r : LicensePart " / > 
< /xsd : complexContent > 
< /xsd : complexType > 

< /xsd : element > 

<xsd : element name= " stateRef erenceValuePattern" 
type= " sx : Stat eRef erenceValuePattern" subst itut ionGroup* " r : anXmlPatternAbs tract " / > 

<xsd: element name=" territory" type="sxs Territory" 
substitut ionGroup= ° r : condition" / > 

<xsd: element name~"trackQuery" type-"sx:TrackQuery" 
subs t itut ionGroup= " r : condit ion " / > 

<xsd: element name="trackReport" type="sx:TrackReport" 
substitut ionGroup= " r : condition" / > 

<xsd : element name- " transf erControl " type= " sx : Transf erControl" 
subst itut ionGroup= " r : condition" / > 

<xsd: element name="uddi" type="sx:Uddi" 
substitut ionGroup= "r 5 serviceDescript ion" / > 

<xsd: element name="validitylntervalDurationPattern" 
t ype = " sx : Validity Int ervalDurat ionPat t ern " 
subst itut ionGroup= " r : condit ionPatternAbs tract " / > 

<xsd: element name="validityIntervalFloating" 
type="sx:ValidityIntervalFloating" subst itutionGroup="r : condition" /> 

<xsd : element name= " validitylntervalStart sNow" 
type= " sx : ValiditylntervalStart sNow" subst itut ionGroup= "r : condition" / > 

<xsd: element name="validityTimeMetered" type="sx:ValidityTimeMetered" 
substitut ionGroup= "r : condition" / > 

<xsd : element name= "validityTimePer iodic " type= " sx : ValidityTimePeriodic " 
substitut ionGroup= "r : condition" /> 

<xsd: element name ="wsdlAddr ess" type = n sx:WsdlAddr ess" 
substitutionGroup="r: serviceDescript ion"/ > 

<xsd: element name="wsdlComplete" type="sx : WsdlComplete" 
substitut ionGroup= "r : serviceDescript ion" / > 
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<xsd: element name ="x5 09 Subject Name" type = w sx:X5 09 Subject Name" 
subs titut ionGroup* " sx : name ■ / > 

<xsd : element name= "x509Sub jectNamePattern" type= n sx : X509Sub jectNamePattern " 
substitut ionGroup= n r : resourcePat ternAbs tract " / > 

<!-- Complex Types --> 

<xsd : complexType name= "Account Payable " > 
<xsd:choice> 

<xsd: element name =" payment Service" > 
<xsd : complexType > 
<xsd: sequence > 

<xsd : element ref = n r : servlceRef erence " / > 
< /xsd : sequence) 
< /xsd : complexType > 
< /xsd : element > 
<xsd: element name- "aba" > 
<xsd : complexType > 
<xsd: sequence > 

<xsd: element name- ■ institution" > 
< xs d : s impleType > 

<xsd : restriction base- "xsd : integer" > 

<xsd: totalDigits value="9"/> 
< /xsd : restriction) 
< /xsd : s impleType > 
< /xsd : element > 

<xsd:element narae= "account " type= "xsd: integer" /> 
< /xsd : sequence > 
< /xsd : complexType > 
< /xsd : element > 

<xsd:any namespace="##other" processContents="lax" /> 
</xsd:choice> 
</xsd:complexType> 

<xsd : complexType name= " AnonymousStat eService " > 

<xsd : complexCont ent > 

<xsd: extension base="r: ServiceDescription"/> 

< /xsd : complexCont ent > 
< /xsd: complexType > 

<xsd : complexType name= " CallForCondit ion " > 
<xsd : complexCont ent > 

<xsd : extension base= " r : Condition" > 
<xsd: sequence minOccurs="0" > 

<xsd: element ref ="r: service Ref erence" maxOccurs= "unbounded" /> 
</xsd: sequence > 
< /xsd: extension > 
< /xsd : complexCont ent > 
< /xsd: complexType > 

<xsd: complexType name="CommonName" mixed="true" > 

<xsd:complexContent mixed="true"> 
<xsd: extension base- "sx: Name" /> 

< /xsd : complexContent > 
< /xsd: complexType > 

<xsd: complexType name= "DnsName " mixed="true" > 

<xsd : complexContent mixed= " true " > 
<xsd: extension base="sx:Name" /> 

< /xsd : complexContent > 
< / x s d : c omp lexType > 

<xsd : complexType name="EmailName" mixed="true" > 

<xsd: complexContent mixed= " true " > 
<xsd: extension base="sx:Name"/> 

< /xsd : complexContent > 
< /xsd : complexType > 
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<xsd : complexType name= " ExerciseLimit n > 
<xsd:complexContent> 

<xsd : extension base= n sx : St atef ulCondit ion ■ > 
<xsd : sequence> 

<xsd:element name="count" type="xsd: integer" minOccurs="0" /) 
</xsd: sequence) 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd: complexType> 
<xsd : complexType name= " FeeFlat " > 

< xs d : complexCont en t > 

<xsd : extension base- " sx : Stat ef ulCondit ion " > 
<xsd : sequence minOccurs="0" > 
<xsd: element ref="sx:rate"/> 

<xsd:element name="to n type="sx: AccountPayable" minOccurs="0"/) 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexContent ) 
< /xsd : complexType) 

<xsd: complexType narae="FeeMetered" > 
<xsd: complexContent) 

<xsd : extension base= "r : Condition" > 
<xsd : sequence minOccurs="0") 

<xsd: element ref ="sx:rate"/> 

<xsd:element name="per" type= "xsd: duration"/) 
<xsd: element name = "by" type= "xsd: duration"/) 
<xsd: element name= "phase" type= "xsd: duration"/) 

<xsd:element name="to" type="sx:AccountPayable" minOccurs="0"/> 
< /xsd : sequence > 
< /xsd : extension) 
< /xsd : complexContent ) 
< /xsd : complexType) 

< xsd : complexType name= " FeePer Interval " > 

< xsd : complexContent > 

<xsd : extension base= " sx : Statef ulCondit ion" ) 
<xsd : sequence minOccurs="0" > 
<xsd: element ref ="sx: rate" /) 

<xsd:element name="per" type= "xsd: duration" /) 

<xsd: element name="to" type="sx: Account Payable" minOccurs="0"/> 
< /xsd : sequence > 
< /xsd : extension) 
< /xsd : complexContent ) 
< /xsd : complexType) 

<xsd : complexType name="FeePerUse" > 
<xsd : complexContent > 

<xsd : extension base= " r : Condition " > 
<xsd: sequence minOccurs="0"> 
<xsd: element ref ="sx: rate"/) 

<xsd: element name="to" type- "sx: Account Payable" minOccurs="0" /) 
< /xsd: sequence) 
< /xsd : extension) 
< /xsd : complexContent ) 
< /xsd : complexType) 

<xsd : complexType name= " FeePerUsePrePay " ) 
<xsd : complexContent > 

<xsd : extension base= " sx : Statef ulCondition " ) 
<xsd: sequence minOccurs="0"> 
<xsd: element ref ="sx: rate"/) 

<xsd : element name= " initialNumberOf Uses " type= "xsd : integer " 

minOccurs="0"/> 
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<xsd : element name= " to" type="sx: Account Payable" minOccurs="0 n /> 
</xsd:sequence> 
< /xsd : extens±on> 
< /xsd : complexContent > 
< /xsd : complexType> 

<xsd:complexType name= " LicenseldPat tern " > 

<xsd : complexContent > 

<xsd : extension base= n r : AnXmlPatternAbs tract " / > 

< /xsd : complexContent > 
< /xsd : complexType> 
<xsd : complexType name="Name") 

<xsd : complexContent > 

<xsd : extension base= n r : Proper tyAbs tract " / > 

< /xsd : complexContent > 
< /xsd : complexType > 

<xsd : complexType name= "Proper tyUri" > 
<xsd : complexContent > 

<xsd : extension base- n r : Proper tyAbs tract " > 

<xsd : attribute name= n definition " type= "xsd : anyURI " / > 
< /xsd : extension> 
< /xsd : complexContent > 
< /xsd : complexType > 
<xsd: complexType name=*"Rate" > 
<xsd z complexContent > 

<xsd : extension base= " r : LicensePart " > 
<xsd: sequence minOccur s = " 0 " > 

<xsd: element name= "amount" type="xsd: float" /> 

<xsd:element name- "currency" type="xsd:QName" minOccurs="0"/> 
< /xsd : sequence > 
< /xsd : extension > 
< /xsd : complexContent > 
< /xsd : complexType > 

<xsd: complexType name=" Right Uri"> 
<xsd : complexContent > 

<xsd: extension base="r: Right "> 

<xsd : attribute name= " definition " type= "xsd: anyURI " / > 
</xsd: extension) 
< /xsd : complexContent > 
< /xsd : complexType> 

<xsd : complexType name= " SeekApproval " > 

<xsd : complexContent > 

<xsd : extension base= " sx : Stat efulCondit ion" / > 

< /xsd : complexContent > 
< /xsd : complexType > 

<xsd : complexType name= " Statef ulCondition" > 
<xsd : complexContent > 

<xsd : extension base= " r : Condition " > 
<xsd : sequence > 

<xsd:element ref ="r : serviceRef erence" minOccurs="0" /> 
< /xsd : sequence) 
< /xsd; extension) 
< /xsd : complexContent > 
< /xsd : complexType) 

<xsd : complexType name= " St at eRef erenceValuePat tern " > 
<xsd : complexContent) 

<xsd: extension base= " r : AnXmlPatternAbs tract " ) 
<xsd: sequence minOccurs="0"> 

<xsd: any name space = " ##any" processContents= "lax" 
maxOccurs= "unbounded" / > 

< /xsd : sequence) 
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< /xsd : extension) 
< /xsd : complexContent > 
< /xsd: complexType) 

<xsd:complexType name= B Territory " > 
<xsd : complexContent > 

<xsd : extension base= "r : Condition" > 

<xsd: choice minOccurs="0" raaxOccurs= " unbounded " > 
<xsd : element name=" location") 
<xsd : complexType> 
<xsd : sequence) 

<xsd: element name = "country n type="xsd:QName" 



minOccur s = " 0 " / > 
minOccurs= " 0 " / > 
minOccur s = B 0"/> 
minOccur s - " 0 " / > 
minOccur s = " 0 " / > 
minOccur s= " 0 " / > 



<xsd: element name- "region" type="xsd:QName" 
<xsd:element name= n state" type= "xsd : string" 
<xsd: element name="city" type= "xsd: string" 
<xsd:element name-"postalCode" type- "xsd: string" 
<xsd: element name- "street " type= "xsd: string" 



< /xsd: sequence) 
< /xsd : complexType > 
< /xsd : element > 
<xsd: element name= " domain " > 
<xsd : complexType) 
<xsd: sequence) 

<xsd: element name="uri" type= "xsd : anyURI " / ) 
< /xsd: sequence) 
< /xsd : complexType) 
< /xsd : element ) 
< /xsd : choice > 
< /xsd : extension) 
< /xsd : complexContent > 
</xsd: complexType) 

<xsd: complexType name = " Tr ackQuery " ) 
<xsd: complexContent) 

<xsd : extension base- " sx : Statef ulCondi tion" ) 
<xsd: sequence) 

<xsd:element name="notLessThan" type= "xsd: integer" minOccurs="0"/> 
<xsd: element name ■ " no tMoreThan " type= "xsd: integer" minOccurs="0"/> 
</xsd: sequence) 
</xsd: extension) 
< /xsd : complexContent ) 
< /xsd : complexType) 

<xsd : complexType name= "TrackReport " > 
<xsd : complexContent ) 

<xsd : extension base= " sx : Statef ulCondit ion" > 
<xsd : sequence) 

<xs d : element name = " communicat ionFailurePol icy " default = " required " 

minOccur s =" 0 " > 

<xsd : simpleType) 

<xsd : restriction base= "xsd : NMTOKEN " ) 
<xsd: pattern value="lax"/) 
<xsd: pattern value= "required"/) 
< /xsd : restriction) 
< /xsd : simpleType) 
< /xsd : element ) 
</xsd: sequence) 
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< /xsd : extension > 
< /xsd : complexCont ent > 
< /xsd : complexType> 

<xsd : complexType name= "Trans f erControl ■ > 
<xsd : complexCont ent > 

<xsd : extension base= M sx : Statef ulCondit ion " / > 
< /xsd : complexCont ent > 
< /xsd : complexType > 
<xsd: complexType name="Uddi"> 
<xsd : complexContent > 

<xsd : extension bas e = " r : ServiceDescript ion " > 
<xsd : sequence minOccur s = n 0" > 

<xsd: element name= "serviceKey" type= " sx : UddiKey " / > 
<xsd: element name - "registry" type ■ "xsd :anyURI" minOccurs= n 0" /> 
</xsd: sequence > 
< /xsd: extension > 
< /xsd : complexCont ent > 
< /xsd : complexType > 
<xsd : complexType name = "UddiKey" > 
<xsd: choice > 

<xsd: element name="uuid" type="sx:Uuid"/> 
<xsd: element name="uri" type= "xsd : anyURI " / > 
< /xsd : choice > 
< /xsd : complexType > 

<xsd : complexType name= " ValiditylntervalDurat ionPattern" > 
<xsd : complexContent > 

<xsd : extension base= "r : Condit ionPat ternAbstract " > 
<xsd: sequence minOccurs="0"> 

<xsd:element name=" duration" type= "xsd: duration"/) 
< /xsd: sequence > 
< /xsd : extension > 
< /xsd : complexContent > 
< /xsd : complexType > 

<xsd: complexType name= " Validity IntervalFloat ing " > 
<xsd : complexContent > 

<xsd : extension base= " sx : Statef ulCondit ion" > 
<xsd: sequence > 

<xsd:element name- "duration" type =" xsd: duration" minOccurs="0"/> 
</xsd: sequence > 
< /xsd: extension > 
< /xsd : complexContent > 
< /xsd : complexType > 

<xsd: complexType name="ValidityIntervalStartsNow" > 
<xsd : complexContent > 

<xsd: extension base="r: Condition" > 
<xsd: sequence rainOccurs="0"> 

<xsd : element ref = " r : validity Interval " / > 

<xsd: element name= "backwardTolerance" type= "xsd: duration" 

minOccur s= " 0 " / > 

<xsd : element name= " f orwardTolerance " type= "xsd : duration " 

minOccur s = " 0 " / > 

</xsd: sequence) 
< /xsd : extension) 
< /xsd : complexContent > 
< /xsd : complexType) 

<xsd : complexType name= " ValidityTimeMetered" > 
<xsd : complexContent > 

<xsd : extension base= " sx : Statef ulCondit ion" > 
<xsd : sequence) 

<xsd: element name = "duration" type="xsd: duration" minOccurs="0"/> 
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<xsd: element name=" quantum" type= "xsd : duration ■ minOccurs="0"/> 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd : complexType> 

<xsd: complexType name= n Valid! tyTimePer iodic" > 
<xsd : complexCont ent > 

<xsd : extension base= "r : Condition ■ > 
<xsd : sequence minOccurs="0"> 

<xsd:element name=" start" type="xsd:dateTime"/> 
<xsd:element name="period" type= "xsd: duration"/) 
<xsd:element name="phase" type= "xsd: duration" minOccurs="0" /> 
<xsd:element name="duration" type« "xsd: duration"/) 
<xsd: element name="periodCount" type= "xsd :nonNegative Integer" 

minOccur s = " 0 " / ) 

< /xsd : sequence > 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd: complexType) 

<xsd : complexType name= " WsdlAddress " > 
<xsd : complexCont ent > 

<xsd: extension base="r :ServiceDescription"> 
<xsd: sequence minOccurs="0"> 
<xsd: element name="kind"> 
<xsd: complexType) 
<xsd : sequence) 

<xsd: element name="wsdl" type="r : Digit alResource" /> 
<xsd: element name=" binding" type= "xsd: QName " / > 
< /xsd : sequence) 
< /xsd : complexType) 
< /xsd : element) 

<xsd: element name=" address") 
<xsd : complexType) 
<xsd : sequence) 

<xsd:any naraespace="##any" processContents="lax n /) 
< /xsd: sequence) 
< /xsd : complexType) 
< /xsd : element) 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexCont ent ) 
< /xsd : complexType) 

<xsd : complexType name="WsdlComplete" > 
<xsd: complexCont ent) 

<xsd : extension base= " r : ServiceDescript ion" > 
<xsd: sequence minOccurs="0") 

<xsd:element name="wsdl" type="r :DigitalResource"/) 
<xsd:element name=" service" type= "xsd: QName"/) 
<xsd:element name=" port Type" type =" xsd: QName" minOccurs="0"/) 
< /xsd : sequence) 
< /xsd : extension) 
</xsd: complexCont ent) 
< /xsd : complexType) 

<xsd: complexType name="X5 09 Subject Name" mixed=" true" ) 

<xsd: complexCont ent mixed="true" > 
<xsd: extension base = " sx : Name " / > 

< /xsd : complexCont ent ) 
< /xsd : complexType) 

<xsd: complexType name="X509Sub jectNamePattern" mixed="true") 
<xsd: complexCont ent mixed="true" > 
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<xsd : extension base= " r : ResourcePatt ernAbstract " / > 
< /xsd : complexCont ent > 
< /xsd : complexType > 
<!-- Simple Types --> 

<xsd : simpleType name= " Prof ileCompliance n > 

<xsd :11st itemType="xsd:QName"/> 
</xsd: simpleType> 
<xsd: simpleType name="Uuid"> 

<xsd: restriction base- "xsd: string" > 
<xsd: length value="36"/> 

< /xsd : restriction> 
< /xsd: simpleType > 
<!-- Attributes --> 

<xsd : attribute name= "prof ileCompliance " type= " sx : Prof ileCompliance " / > 
< /xsd: schema > 



A.4 Schema for the Multimedia Extension Namespace 

<?xml version="1.0" encoding="UTF-8" ?> 

<xsd: schema tar get Name space= "urn :mpeg:mpeg21 : 2003 : 01-REL-MX-NS" 
xrolns : rax= n urn : rapeg : mpeg2 1 : 2003 : 01-REL-MX-NS" 
xralns :r= "urn :mpeg:mpeg21: 2003 : 01-REL-R-NS" 
xralns:dsig="http: //www.w3.org/2000/09/xmldsig#" 
xmlns :xsd="http: //www.w3 . org/ 2 001 /XML Schema" 

element FormDefault= "qualified" attributeFormDef ault= "unqualified" > 

<xsd: import namespace= "urn :mpeg:mpeg21 : 2003 : 01-REL-SX-NS" schemaLocation="rel- 
sx.xsd°/> 

<xsd: import namespace= "urn :mpeg :mpeg21 : 2003 : 01-REL-R-NS" schemaLocation="rel- 
r.xsd"/> 

< x s d : import namespace = " ht tp : / /www . w3 . org/ 2000/09 /xmldsig# " 

schemaLocation="http: //www. w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core- 
scheroa . xsd" / > 

<! > 

<!-- ===== Rights ===== --> 
<l > 

<xsd: complexType name= "Modify" > 
<xsd : complexContent > 

<xsd : extension base="r : Right "/> 
</xsd: complexCont en t > 
< /xsd : complexType > 
<xsd: complexType name= " Enlarge " > 
<xsd : complexContent > 

<xsd : extension base= " r : Right " / > 
< /xsd : complexContent > 
< /xsd : complexType > 
<xsd: complexType name== "Reduce" > 
<xsd : complexContent > 

<xsd: extension base="r: Right "/> 
< /xsd : complexContent > 
< /xsd : complexType> 
<xsd: complexType name="Move"> 
<xsd : complexCont ent > 

<xsd: extension base="r : Right "/> 
< /xsd : complexContent > 
< /xsd: complexType > 
<xsd : complexType name= "Adapt "> 
<xsd: complexCont ent > 

<xsd: extension base="r : Right "/> 
< /xsd: complexCont ent > 
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< /xsd : complexType> 

<xsd : complexType name- "Diminish" > 
<xsd : coraplexContent > 

<xsd: extension base="r : Right n /> 
< /xsd : complexContent > 
< /xsd : complexType> 
<xsd: complexType name= " Enhance" > 
<xsd : complexContent > 

<xsd: extension base="r : Right" /> 
< /xsd : complexContent > 
< /xsd : complexType > 
<xsd: complexType name=" Embed" > 
<xsd : complexContent > 

<xsd: extension base-"r : Right " /> 
< /xsd : complexContent > 
< /xsd : complexType > 
< xsd: complexType name- " Play" > 
<xsd: complexContent > 

<xsd: extension base-"r : Right" /> 
< /xsd : complexContent > 
< /xsd : complexType > 
<xsd: complexType name-" Print "> 
<xsd: complexContent > 

<xsd: extension base-"r : Right "/> 
< /xsd : complexContent > 
< /xsd : complexType > 
<xsd: complexType naine= " Execute " > 
< xsd : complexContent > 

<xsd: extension base- "r: Right "/> 
< /xsd : complexContent > 
< /xsd : complexType> 
<xsd: complexType name-" Install" > 
<xsd : complexContent > 

<xsd: extension base="r: Right" /> 
< /xsd : complexContent > 
< /xsd : complexType> 

<xsd: complexType name="Uninstall" > 

<xsd : complexContent > 

<xsd: extension base="r: Right" /> 

< /xsd: complexContent > 
< /xsd : complexType > 
<xsd : complexType name= " Delete "> 

<xsd: complexContent > 

<xsd: extension base="r: Right " /> 

< /xsd : complexContent > 
< /xsd : complexType> 

<xsd:element name = "modify" type- "mx: Modify" substitutionGroup="r : right /> 
<xsd:element name=" enlarge" type- "mx: Enlarge" substitutionGroup="r : right" /> 
<xsd:element name="reduce" type- "mx: Reduce" substitutionGroup-"r : right "/> 
<xsd:element name =" move" type- "mx: Move" substitutionGroup="r -.right "/> 
<xsd:element name="adapt" type- "mx: Adapt " substitutionGroup-"r :right "/> 
<xsd:element name- "diminish" type- "mx: Diminish" substitutionGroup="r : right "/> 
<xsd: element name- "enhance" type- "mx: Enhance" subs ti tut ionGroup- "r : right" /> 
<xsd:element name="embed" type- "mx: Embed" substitutionGroup="r : right "/> 
<xsd:element name-"play" type- "mx: Play" substitutionGroup-"r :right" /> 
<xsd:element name="print" type- "mx: Print " subs titut ionGroup- "r : right " /> 
<xsd:element name- "execute" type- "mx: Execute" subs titut ionGroup- "r : right " /> 
<xsd:element name- "install" type- "mx: Install" substitutionGroup- "r: right"/ > 
<xsd: element name- "unins tall" type- "mx:Uninst all" 
subs t i tut ionGroup- " r : right " / > 



© ISO/IEC 2003 — All rights reserved 



83 



ISO/IEC FDIS 21000-5:2003(1 



# 



<xsd : element name = "delete" type= "mx : Delete" subst itutionGroup= "r: right " / > 
<! > 

<!-- === Resources === - - > 
<!-- --) 

<!-- Digital Item Resources 
<xsd : complexType name= "Di I temRef erence" > 
<xsd : complexCont ent > 

<xsd : ext ens ion base= " r : Resource " > 
<xsd: sequence minOccurs="0" ) 

<xsd: element name=" identifier" type="xsd: anyURI n /> 
</xsd: sequence > 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd : complexType > 

<xsd: complexType name = " DiRef erence " > 
<xsd : complexCont ent > 

<xsd: extension base="r: Resource" > 
<xsd: sequence minOccurs="0" > 

<xsd:element name="identif ier " type="xsd:anyURI"/> 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd : complexType > 

<xsd : element name= " dil temRef erence " type= "mx : Dil temRef erence " 
substitutionGroup= "r : resource " / > 

<xsd : element name = " diRef erence " type= "mx : DiRef erence " 
substitutionGroup= "r : resource" / > 

< I > 

<!-- === Conditions === --> 
<! > 

<!-- Digital Item Conditions --> 
<xsd: complexType name- "DiCriteria" > 
<xsd : complexCont ent > 

<xsd : extension base= "r : Condition" > 
<xsd: sequence minOccurs=»"0" > 

<xsd: element ref="mx: diRef erence"/) 

<xsd:element ref ="r: anXmlPatternAbs tract" maxOccurs=" unbounded"/) 
< /xsd : sequence) 
< /xsd: extension) 
< /xsd : complexCont ent > 
< /xsd : complexType) 

<xsd: complexType name="DiPartOf " > 
<xsd : complexCont ent) 

<xsd : extension base= "r : Condition" ) 
< xsd : sequence minOccur s = " 0 " > 

<xsd : element ref = "mx : diRef erence " / > 
<xsd : element ref = "mx : diRef erence " / > 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd: complexCont ent) 
< /xsd : complexType > 

<xsd: element name="diCriteria" type="mx: DiCriteria" 
subst itutionGroup= " r : condition "/ > 

<xsd: element name="diPartOf " type= "mx : DiPartOf " 
subst itutionGroup= "r : condition " / > 
<!-- Marking Conditions --) 
<xsd: complexType narae= " I s Marked" > 
<xsd : complexCont ent > ? 

<xsd: extension base="r: Condition") 
<xsd: sequence minOccurs="0" > 
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<xsd:element ref ="r: resource"/) 

<xsd:any namespace- "##any" processContents="lax B /> 
</xsd: sequence > 
< /xsd : extension> 
< /xsd : complexCont ent > 
< /xsd : complexType> 
<xsd : complexType name = n Mark ■ > 
<xsd: complexCont ent > 

<xsd : extension base- " r : Condition" > 
<xsd: sequence minOccurs="0"> 

<xsd: element ref ="r: resource" /> 

<xsd:any namespace="##any" processContents-"lax"/> 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd : complexType > 

<xsd:element name="isMarked" type-"mx: IsMarked" 
substitutionGroup-"r: condition"/) .... - /s 

<xsd:element name-"mark" type- "mx: Mark" substitutionGroup="r : condition /> 
<l-- Security Conditions --> 
<xsd: complexType name =" Source " > 
<xsd : complexCont ent > 

<xsd : extension base= " r : Condition" > 
<xsd: sequence minOccurs-"0" > 

<xsd: element ref -"r: principal"/) 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd i complexCont ent > 
< /xsd : complexType) 

<xsd s complexType name= " Des t inat ion " > 
<xsd : complexCont ent > 

<xsd : extension base= "r : Condition" > 
<xsd: sequence minOccurs="0"> 

<xsd: element ref ="r: principal"/) 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd : complexType) 
<xsd: complexType name="Helper" > 
<xsd : complexCont ent ) 

<xsd : extension base- " r : Condition" ) 
<xsd: sequence) 

<xsd:element ref ="r :principal" minOccurs="0" 

raaxOccurs= "unbounded" / > „ _ _ _„ 

<xsd:element name- "wildcard" minOccurs-"0" maxOccurs- unbounded 

<xsd : complexType) 
<xsd: sequence) 

<xsd:element ref ="r :anXmlPatternAbstract" minOccurs= 0 

maxOccur s= " unbounded" / ) 

< /xsd : sequence) 
< /xsd : complexType) 
< /xsd: element) 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd: complexCont ent) 
< /xsd : complexType) 
<xsd: complexType name =" Render er " > 
<xsd : complexCont ent > 

<xsd : extension base= "r : Condition" ) 
<xsd: sequence) 
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<xsd: element ref= n r : principal" rainOccurs= "0" 
maxOccur s = " unbounded " / > 

<xsd: element narae= "wildcard" minOccurs="0" maxOccurs= "unbounded" > 
<xsd : complexType > 
<xsd : sequence) 

<xsd: element ref ="r :anXmlPatternAbs tract " minOccurs="0" 

maxOccur s= "unbounded" / > 

< /xsd : sequence > 
< / xs d : c omp lexType > 
< /xsd : element > 
</xsd: sequence) 
< /xsd : extension) 
< /xsd : complexCont ent > 
< /xsd : complexType) 

<xsd : complexType name= " ResourceSignedBy " ) 
<xsd : complexCont en t ) 

<xsd: extension base="r: Condition") 
<xsd: sequence minOccurs="0" ) 

<xsd:element ref ="dsig:CanonicalizationMethod"/) 
<xsd : element ref = "dsig : SignatureMethod" / ) 
<xsd: element ref ="r: resource"/) 

<xsd:element ref = " ds ig : Transforms " minOccurs="0" /> 
<xsd : element ref = " dsig : Diges tMethod" / > 
<xsd: element ref ="r: principal"/) 
< /xsd : sequence) 
< /xsd : extension) 
< /xsd : complexContent > 
< /xsd : complexType > 

<xsd:element name=" source" type="mx: Source" substitutionGroup-"r : condition"/) 
<xsd: element name = "destination" type="mx: Destination" 
substitutionGroup= "r : condition " / ) 

<xsd:eleroent name="helper" type="mx: Helper" substitutionGroup="r : condition"/) 
<xsd:element name="renderer" type="mx: Render er" 
substitutionGroup= "r : condition " / ) 

<xsd : element name- "resourceSignedBy " type= "mx : ResourceSignedBy" 
subst itut ionGroup= "r : condition " / ) 
<!-- Transactional Conditions --> 
<xsd : complexType name = "Transact ion" ) 
<xs d : complexContent > 

<xsd : extension base= "r : Condition " ) 
<xsd: sequence minOccurs="0") 

<xsd: element ref ="r : serviceRef erence"/) 
< /xsd: sequence) 
< /xsd : extension) 
< /xsd : complexContent ) 
< /xsd : complexType) 

<xsd: element narae= "transaction" type= "mx : Transaction " 
substitutionGroup="r : condition"/) 

<!-- Resource Attribute Conditions --> 
<xsd: complexType name="RequiredAttributeChanges" ) 
<xsd : complexContent ) 

<xsd : extension base= " r : Condition " > 

<xsd: choice minOccurs="0" maxOccurs=" unbounded") 
<xsd : element ref = "mx : complement " / ) 
<xsd: element ref = "mx : intersection" / ) 
<xsd: element ref ="mx: set "/> 
<xsd: element ref = "mx : union" /) 
</xsd: choice) 
< /xsd : extension) 
< /xsd : complexContent > 
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< /xsd : complexType> 

<xsd : complexType name= " ProhibitedAttributeChanges n > 
<xsd : complexContent > 

<xsd : extension base="r: Condition " > 

<xsd: choice minOccurs="0 B maxOccurs= "unbounded" > 
<xsd : element ref="mx : complement " / > 
<xsd : element ref = "mx : intersection " / > 
<xsd: element ref ="mx: set "/> 
<xsd : element ref ="mx: union" /> 
</xsd:choice> 
< /xsd: extension > 
< /xsd : complexContent > 
< /xsd : complexType > 

<xsd: element name="requiredAttributeChanges" 
type= "mx ; RequiredAttributeChanges ■ substitutionGroup= "r : condition" / > 

<xsd : element name= "prohibit edAttributeChanges " 
type="mx: ProhibltedAttributeChanges" substitutionGroup="r : condition" /> 

<!-- Resource Attribute Set Definitions 

<xsd : element name = "complement " subst itutionGroup= " r : licensePar t " > 
<xsd : complexType > 

<xsd: complexContent > 

<xsd : extension base- "r : LicensePart " > 
<xsd: choice minOccurs="0" ) 

<xsd:element ref = "mx : complement " / > 
<xsd : element ref = "mx : intersection " / > 
<xsd: element ref ="mx:set"/> 
<xsd: element ref ="mx: union" /> 
</xsd:choice> 
< /xsd : extension) 
</xsd: complexCon t en t > 
< /xsd: complexType > 
< /xsd : element > 

<xsd : element name = "intersection" substitut ionGroup= "r : licensePart " > 
<xsd : complexType > 

<xsd : complexContent > 

<xsd : extension base= " r : LicensePart " > 

<xsd: choice minOccurs="0" maxOccurs= "unbounded" > 
<xsd: element ref = "mx : complement " / > 
<xsd : element ref = "mx : intersection " / > 
<xsd: element ref ="mx: set "/> 
<xsd: element ref ="mx: union" /> 
< /xsd : choice> 
< /xsd : extension > 
< /xsd : complexContent > 
< /xsd : complexType> 
< /xsd: element > 

<xsd : element name= " set " subs t itut ionGroup= " r : licensePart " > 
<xsd : complexType > 

<xsd : complexContent > 

< xsd : extension base= " r : LicensePart " > 
<xsd: sequence) 

<xsd:any namespace="##any" minOccurs="0" 
maxOccurs= "unbounded" / > 

< /xsd : sequence) 

<xsd: attribute name- "definition" type="xsd : anyURI" 
use= " optional " / > 

< /xsd : extension) 
< /xsd : complexContent ) 
< /xsd : complexType) 
< / xsd : element > 
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<xsd:eleraent name=" union" subst itutionGroup= "r : licensePart " > 
<xsd : complexType > 

<xsd : complexContent > 

<xsd : extension base= "r : LicensePart " > 

<xsd: choice minOccurs-"0" maxOccurs= "unbounded" > 
<xsd : element ref="rax: complement " / > 
<xsd: element ref = "mx : intersection" / > 
<xsd: element ref = "mx: set "/> 
<xsd: element ref ="mx: union" /> 
< /xsd : choice> 
< /xsd : extension > 
< /xsd : complexContent > 
< /xsd : complexType > 
< /xsd : element > 
</xsd: schema > 



88 



© ISO/IEC 2003 



All rights reserved 




ISO/IEC FDIS 21000-5:2003(E) 



Annex B 

(normative) 



Country, region, and currency Qualified Names 



B.1 Namespace URI structure 

The namespaces of the Qualified Names defined in this Annex shall be identified by a URI of the form 
urn:mpeg:mpeg2l:2003:0l-REL-sx-NS:iryT3r:rypjB, where yyyy indicates any year after or including 
2003 and type, which is either country, region, or currency, indicates the type of Qualified Names the 
namespace contains. 

NOTE In order to support the consistent meaning of Licenses over time, countries, regions, and currencies are 
indicated by Qualified Names. Utilizing the facilities provided by ISO 3166 and ISO 4217, this Annex defines an algorithm 
for generating a number of such Qualified Names, grouped into a number of namespaces. 



B.2 Country Qualified Names 

The local part of the country Qualified Names defined in this Annex is the ISO 3166-1 country code. 

The country namespace urn:mpeg:mpeg21:2003:01-REL-SX-NS:2003:country contains one 
Qualified Name for each ISO 3166-1 country code in use during 2003. The other country namespaces 
defined in this Annex contain one Qualified Name for each ISO 3166-1 country code that appears in an ISO 
3166-1 publication during the respective year. 

The meaning of any country Qualified Name q defined in this Annex is the same as the meaning that the ISO 
3166-1 country code corresponding to the local part of q had during the year corresponding to the namespace 
of q. 

Qualified names from the urn:mpeg:mpeg21:2003:01-REL-sx-NS:2003;country namespace should 
be used to refer to a country whenever possible. In the event it is not possible to use a Qualified Name from 
this namespace, the Qualified Name from the namespace with the earliest yyyy value and still referring to the 
desired country should be used instead. If neither of these is possible, any Qualified Name referring to the 
desired country may be used. 



B.3 Region Qualified Names 

The local part of the region Qualified Names defined in this Annex is the ISO 3166-2 region code. 

The region namespace urn:mpeg:mpeg2l:2003:0l-REL-sx-NS:2003:region contains one Qualified 
Name for each ISO 3166-2 region code in use during 2003. The other region namespaces defined in this 
Annex contain one Qualified Name for each ISO 3166-2 region code that appears in an ISO 3166-2 
publication during the respective year. 

The meaning of any region Qualified Name q defined in this Annex is the same as the meaning that the ISO 
3166-2 region code corresponding to the local part of q had during the year corresponding to the namespace 
of 

Qualified names from the urn:mpeg:mpeg2l : 2003 : 01-REL-sx-NS : 2003 : region namespace should be 
used to refer to a region whenever possible. In the event it is not possible to use a Qualified Name from this 
namespace, the Qualified Name from the namespace with the earliest yyyy value and still referring to the 
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desired region should be used instead. If neither of these is possible, any Qualified Name referring to the 
desired region may be used. 



B.4 Currency Qualified Names 

The local part of the currency Qualified Names defined in this Annex is the ISO 4217 currency code. 

The currency namespace urn:mpeg:mpeg2l: 2003 :0l-REL-sx-NS: 2003 :currency contains one 
Qualified Name for each ISO 4217 currency code in use during 2003. The other currency namespaces 
defined in this Annex contain one Qualified Name for each ISO 4217 currency code that appears in an ISO 
4217 publication during the respective year. 

The meaning of any currency Qualified Name q defined in this Annex is the same as the meaning that the ISO 
4217 currency code corresponding to the local part of q had during the year corresponding to the namespace 
of q. 

Qualified names from the urn:mpeg:mpeg21: 2003 :01-REL-SX-NS: 2003 : currency namespace should 
be used to refer to a currency whenever possible. In the event it is not possible to use a Qualified Name from 
this namespace, the Qualified Name from the namespace with the earliest yyyy value and still referring to the 
desired currency should be used instead. If neither of these is possible, any Qualified Name referring to the 
desired currency may be used. 
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Annex C 

(informative) 



Simplified equality algorithm 



C.1 General 



There are a number of techniques that can be used to efficiently test for equality without having to actually 
invoke the full Schema Centric Canonicalization algorithm. If the schemas in question are "elat^ely jixed so 
that their structure can be compiled into or otherwise cached by an application, then the assessment of 
whether tSoSSH of XML are Equal or not is straightforward to implement efficiently and might very natural y 
be carried out at me application object model layer. However, if the schemas involved are not so intimately 
kno^lien the task of assessing equality is much more complicated and subtle: considerable flexibility and 
latitude extets in XML Schema wherein "possibly quite different XML Information Sets are considered to 
actually convey the same information. Fortunately, in many of the common cases, rt ,s Ro^todetermine 
whether two pieces of XML are Equal or not without retrieving and processing the associated schemas. This 
teads to mepSs^ to develop a number of auxiliary algorithms, likely differing in exactly jhich set oi 
common cases they cover, that result in Equal or not Equal for the cases they coverand 'ndeterminate for he 
cases they do not cover. One of these possible auxiliary algorithms is presented here (embodied in the 
e?u3Quickltem function defined below) in the belief that it will be of broad ^i^r^areZu^ 
the presentation of this algorithm is not intended to have any normative impact Applications are not equ,red 
to support the same set of common cases supported by this algorrthm. If th,s algorrthm drffers in rts 
determination of Equal from the normative definition of Equal in 6.1 . the normative definition prevails. 

C.2 The equalQuickltem function 

The equalQuickltem function takes two information items, a and p, as inputs and yields etther ^ e .^.^^ 
not Equal, or indeterminate according to whether it determines that the information items ca n be Jeterminec I to 
be Equal or not or that an evaluation by a more comprehensive algorrthm is necessary Let the notion x\y] 
be understood to represent the value of the property whose name is y of the information item x. Then the 
equalQuickltem function is defined as follows. 

If a and p are different kinds of information items, then not Equal is returned. 

If a and p are both element information items, then the following steps are considered in order: 

a) If oTnamespace name] is not identical to ^[namespace name], then not Equal is returned. 

b) If opocal name] is not identical to £[local name], then not Equal is returned. 

c) The sets ^attributes] and ^attributes] are examined to define the value attributesldentical(a, p): 

1) If a permutation p of ^[attributes] exists such that equalQuickList(a[attributes], p) is Equal, then 
attributesldentical(a, p) is Equal. 

2) Otherwise, if «[attributes] contains a member a and ^attributes] contains a member b where both 
afnamespace namel is identical to i>[namespace name] and «[local name] is .dentical to i>[local name 
then, if equalQuickltem(«, b) is not Equal or indeterminate, then attributesldentical(a, p) is not Equal 
or indeterminate, respectively. 

3) Otherwise, attributesldentical(«, p) is indeterminate, due to the potential existence of default 
attributes in the DTD or schema. 
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d) The ordered lists a[children] and ^[children] are examined to define the value childrenldentical(a, 0). Let a 
be the subsequence of a[children] and b be the subsequence of ^[children] consisting of only the element 
and character information items therein (thus, comment, processing instruction, and unexpanded entity 
reference items are ignored, just as they are by XML Schema). 

1) If equalQuickList(a, b) is Equal, then childrenldentical(a, 0) is Equal. That is, an exact match 
guarantees equality. 

2) Otherwise, let A and B be, respectively, the subsequences of a and b containing only element 
information items. If there does not exist a permutation p of b such that equalQuickList(a,p) is Equal 
or indeterminate, then childrenldentical(a, 0) is not Equal. That is, because the potential existence in 
the schema of a model group with a {compositor} of a//, possibly even in a content model with content 
type mixed, we must allow for potential reordering of the elements in comparing for equality. But, if 
no such reordering can be made to work, then we can know for certain that no equality is possible. 

3) Otherwise, if one of the lists a and b is empty and the other contains only character information items, 
then childrenldentical(a, 0) is indeterminate, since the schema might indicate a default content value 
which is Equal to the non-empty list. 

4) Otherwise, if both of the lists a and b contain only character information items, then 
childrenldentical(a, 0) is the value returned by equalQuickSimple(a, b, false). Element content 
consisting entirely of characters might be an occurrence of the use of simple types and so must be 
conservatively evaluated as such. 

5) Otherwise, if at least one of a and b contains any element information items and at least one of a or b 
contains any non-whitespace character information items, then (the content type must be mixed, and 
so) let the character information items in a and b be divided respectively into sequences of sub-lists 
A x through A k and B, through B k such that *-1 is the number of element information items in each of 
a and b (necessarily the same due to d)2) above) and any given A i or B t consists of all those 
character items in order in a or b that are separated therein by two consecutive element items or an 
element item and the start or end of the list as the case may be. If there exists any A i and 
corresponding B t such that equalQuickList^., B t ) is not Equal, then childrenldentical(a, 0) is not 
Equal. That is, the characters used in mixed content must match exactly. 

6) Otherwise, childrenldentical(a, 0) is indeterminate. 

e) If either attributesldentical(a, 0) is not Equal or childrenldentical(a, 0) is not Equal, then not Equal is 
returned. 

f) Otherwise, if either attributesldentical(a, 0) is indeterminate or childrenldentical(a, 0) is indeterminate, 
then indeterminate is returned. 

g) Otherwise, Equal is returned. 

If a and 0 are both attribute information items, then the following steps are considered in order: 

a) If a[namespace name] is not identical to y0[namespace name], then not Equal is returned. 

b) If o[local name] is not identical to #local name], then not Equal is returned. 

c) Otherwise, equalQuickSimple(a[normalized value], ^[normalized value], true) is returned. 
If a and 0 are both character information items: 

a) If a[character code] is the same as ^[character code], then Equal is returned. 

b) Otherwise, not Equal is returned. 
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Otherwise, indeterminate is returned. 



C.3 The equalQuickList function 

The equalQuickList function takes as input two ordered lists of information items a and p and returns Equal, 
not Equal, or indeterminate as follows. 

a) If the size of a differs from the size of p, then not Equal is returned. 

b) If there exists any member a of a and corresponding member b of p such that equalQuickltem(a, b) is not 
Equal, then not Equal is returned. 

c) If there exists any member a of a and corresponding member b of p such that equalQuickltem(a, b) is 
indeterminate, then indeterminate is returned. 

d) Otherwise, Equal is returned. 



C.4 The equalQuickSimple function 

It is intended that equalQuickSimple embody the appropriate comparison tests for a sequence of characters 
that are either known to be or might potentially be the data consisting of a simple type. The equalQuickSimple 
function takes as input two sequences of character information items a and p and a boolean y and returns 
Equal, not Equal, or indeterminate as follows. 

a) If equalQuickUst(a, p) is Equal, then Equal is returned. That is, an exact match guarantees equality. 

b) Otherwise, if y is true, then indeterminate is returned. If a and p are not identical, then their canonicalized 
lexical representations still might be. A more elaborate implementation might perhaps consider each of 
the various data types and their possible canonicalized lexical representations in order to in some 
situations eke out a not Equal instead of indeterminate, but such is not elaborated here. 

c) Otherwise, if y is false, then indeterminate is returned. 
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Annex D 

(informative) 



Example Rights Expressions 



D.1 Overview of examples 

This annex presents both a simple end-user license example and a richer, distribution license example. The 
two examples are related in that the simple end-user license is issued pursuant to the distribution license. 

The two examples, when taken together, demonstrate some of the most typical features of the language and 
illustrate how those features can enable the business model that is presented throughout the course of this 
Annex. 

It is worth noting that the business model presented here does not come at the cost of such Rights Expression 
complexity as to make it impossible for an otherwise-capable resource-constrained device to participate in the 
scenario as an end user device. On the contrary, the end user License lends itself very well to a number of 
optimizations (for instance, compression of the License or targeted interpretation) that would make such 
participation not only possible, but exceedingly practical as well. 

Interpretation of the distribution License is somewhat more involved than interpretation of the end user 
License, but this is the trade-off for increased functionality. While some of the most highly resource- 
constrained devices may have difficulty supporting the functionality of the distribution License, a good system 
designer will typically direct such functionality toward those devices that have sufficient resources for the 
desired level of functionality. 

There are four actors in the following examples: Acme, Alice, John, and Xin. To gain some perspective on the 
resource limitations related to each of the actors, it may help to consider what devices each of them may have. 
Acme maintains a music club. It may be sponsored by a consortium of authors and run a web site on a single 
old personal computer with a 100 MHz processor. Alice is a digital item author. She may have a personal 
computer that she uses to check her e-mail and run her favourite authoring applications. John is an end user 
who wishes to experience Alice's digital item. He might be operating a cell phone with the appropriate display 
or audio capabilities. Xin is a distributor operating a License server providing Licenses on demand to many 
cell phone users like John. Xin's license server might be mirrored for load balancing and likely has significant 
bandwidth, storage, and processor power available to it. 



D.2 Simple end-user License example 

Alice's Digital Item has identifier urn:grid:al-abcde-l234567890-f . John wishes to experience Alice's 
Digital Item. Xin provides the following License to John allowing him to play the Digital Item during 2003: 

<?xml version= n 1.0" encoding="UTF-8" ?> 
<r: license 

xmlns :r= "urn: mpeg :mpeg21 : 2003 : 01-REL-R-NS" 
xmlns : sx= " urn : mpeg : mpeg2 1:2003:0 1-REL-SX-NS n 
xmlns : mx= " urn : mpeg : mpeg2 1 : 2003 : 01-REL-MX-NS" 
xmlns :dsig="http: //www. w3.org/2000/09/xmldsig#" 
xmlns :xsi="http: //www. w3 .org/ 200 1/XMLSchema- instance" 
xsi :schemaLocation= "urn :mpeg :mpeg21 : 2003: 01-REL-MX-NS rel-mx.xsd"> 
<r: grant > 

<r : keyHolder licensePart Id= " John n > 
<r : inf o> 

<dsig:KeyValue> 
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< ds ig : RSAKeyValue> 

<dsig : Modulus >Kt dToQQy zA= = < / ds ig : Modulus > 

< ds ig : Exponent >AQABAA= = < / ds ig : Exponent > 
< / ds ig : RSAKeyValue > 

< / ds ig : Key Value > 

</r:info> 
< /r : keyHolder > 
<mx;play/> 
<mx : diRef erence> 

<mx:identifier>urn:grid:al-abcde-1234567890-f </mx: identifier > 

< /mx : diRef erence> 
<r : validitylnterval> 

<r :notBef ore>2003-01-01T00 : 00 : 00</r : notBef ore> 

<r:notAfter>2004-01-01T00:00:00</r:notAfter> 

< /r : validitylnterval > 
< /r: grant > 

<l--The license is issued by Xin, the distributor . --> 
<r : issuer > 

<r : keyHolder licensePart Id= "Xin" > 
<r:info> 

<dsig : Key Value > 

<dsig : RSAKeyValue> 

< dsig : Modulus >X0 j 9q9 9y z A= = < / dsig : Modulus > 

< ds i g : Exponent > AQABAA= = < / ds i g : Exponent > 
< /dsig r RSAKeyValue > 

< /dsig : Key Value > 
</r :info> 
< /r: keyHolder > 
< /r: issuer > 
</r:license> 

Looking closely at the License above, we observe that it has two parts: an r: grant and an r: issuer, as 
shown in the skeletal License outline below. 

<r: license . * . > 
<r: grant > 

<r : keyHolder licensePart Id= " John" > . • . < /r : keyHolder > 
<mx:play/> 

<mx : diRef erence> • . . </mx: diRef erence) 

<r:validitylnterval>. • . </r: validity Interval> 
</r:grant> 
<r: issuer > 

<r:keyHolder licensePartId= w Xin" > . . . </r: keyHolder > 
</r;issuer> 
</r:license> 

The issuer is Xin. (Note: It is assumed for the purposes of this License that the authenticity and integrity of the 
License are determined by other means. For instance, if Xin owns the cell phone network that John is on, it is 
very possible that he has some other method to insure the authenticity and integrity of his Licenses. 
Optionally, the License could have been signed inside the r: issuer to guarantee the authenticity and 
integrity inline.) The r: grant has four parts: 

a) The r : keyHolder identifies that John is being granted the rights. 

b) The mx : play identifies the right that John is being granted. 

c) The mx: diRef erence identifies the Digital Item, urn:grid:al-abcde-1234567890-f , to which 
John is being granted rights. 
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d) The r:vaiidityinterval Identifies the time interval, 2003, during which John is allowed to play the 
Digital Item. 



D.3 Distribution License example 

In order to issue the end user License shown in D.2, Xin needs to have a License from Alice to do so. Alice, 
however, does not want to give Xin a separate License for each possible person to whom he may want to 
issue. Instead, she prefers to give Xin one License that allows him to issue to any number of people. In doing 
so, she also wants to constrain her License in the following ways: 

— Each time Xin issues a License including an r : grant pursuant to her License, Xin must pay her $1 . 

— The r: grant elements that Xin includes in the Licenses he issues pursuant to her License must have 
the exact Right, play, for an exact Resource (her Digital Item with identification urn : grid: al- abode - 
1234567890-f ) under an exact Condition (that playing occurs during 2003). 

— The r: grant elements that Xin includes in the Licenses he issues pursuant to her License must be 
grants to Principals who are members of Acme music club at the time he issues the Licenses. 

Alice gives Xin the following License: 

<?xml version= "1.0" encoding="UTF-8" ?> 
<r : license 

xmlns : r=" urn: mpeg :mpeg21 : 2003 : 01-REL-R-NS" 
xmlns : sx= " urn : mpeg : rope g2 1:2003:01- REL - SX- NS " 
xmlns : mx= " urn : mpeg : mpeg2 1:2003:0 1 -REL -MX-NS " 
xmlns :dsig="http: //www. w3 .org/200 0/09 /xmldsig#" 
xmlns :xsi="http: //www. w3.org/2001/XMLSchema-instance" 
xsi :schemaLocation= "urn: mpeg :mpeg21 : 2003: 01-REL-MX-NS rel-mx.xsd"> 
<r : grant > 

<r : f orAll varName= " AcmeMusicClubMember " > 
<r :propertyPossessor> 

<sx : propertyUri definitions "urn : acme : musicClubMember " / > 
<r: trustedRoot Issuers > 

<r : keyHolder licensePart Id= "Acme" > 
<r:info> 

<dsig : Key Value > 

<dsig : RSAKey Value > 

<dsig:Modulus>aaaM4ccyzA==</dsig:Modulus> 
<dsig : Exponent > AQABAA= = < / ds ig : Exponent > 
< /dsig : RSAKeyValue> 
</dsig:KeyValue> 
</r:info> 
< /r : keyHolder > 
< / r : trustedRoot I ssuers > 
< /r : propertyPossessor> 
</r:forAll> 

<r:keyHolder licensePart Id= "Xin "> 
<r : inf o> 

<dsig : KeyValue> 

<dsig : RSAKeyValue> 

<dsig:Modulus>X0J9q99yzA==</dsig:Modulus> 
<dsig : Exponent >AQABAA= = < / dsig : Exponent > 
< / ds i g : RSAKey Value > 
</dsig:KeyValue> 
</r:info> 
< /r : keyHolder > 
<r:issue/> 
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<r : grant > 

<r : principal varRef = " AcmeMusicClubMember " / > 

<mx:play/> 

<mx : diRef erenced 

<mx:identifier>urn:grid:al-abcde-1234567890-f </mx: identifier > 

< /mx : diRef erence> 
<r :validitylnterval> 

<r : notBef ore>2003 - 01- 01T00 : 00 : 00< /r : notBef ore> 
<r :notAf ter>2004-01-01T00 : 00 : 00</r :notAf ter> 
< /r : validitylnt erval> 
< /r: grant > 
< sx : f eePerUse > 
<sx:rate> 

< sx : amount > 1 . 0 0 < / sx : amount > 
</sx:rate> 

<sx: to> 

<!--This is Alice's bank account inf ormation. 
<sx:aba> 

<sx:institution>13937158K/sx:institution> 
< sx : account > 1 1 1 1 1 K / sx : account > 
</sx:aba> 
</sx:to> 
< / sx : f eePerUse > 
< /r: grant > 

<l--The license is issued and signed by Alice, the author. --> 
<r : issuer > 

<dsig : Signatured 

<dsig : Signedlnf o> 

<dsig : CanonicalizationMethod 

Algorithm="http://www.w3.org/TR/2001/REC-xml-cl4n-20010315"/> 
<dsig : S i gnat ureMet hod 

Algorithm^ " ht tp : / /www . w3 . org/ 2 00 0 / 0 9 /xmldsig#rsa- shal ■ / > 
<dsig : Referenced 

<dsig : Transforms > 

<dsig: Transform Algorithm- 

"urn :mpeg:mpeg21 : 2003 : 01-REL-R-NS: licenseTransf orm"/> 
< / ds ig : Transforms > 
<dsig:DigestMethod 

Algorithm^ " ht tp : / /www . w3 . org/ 2000/0 9 /xmldsig# shal " / > 
<dsig:DigestValue>Jk9QbKOQCo941tTExbjl/Q==</dsig:DigestValue> 
< /dsig : Referenced 
</dsig ; Signedlnf o> 

<dsig:SignatureValue>DFgqOhh5QQ==</dsig:SignatureValue> 
<dsig : Keylnf o> 

< ds i g : Key Value > 

<dsig : RSAKeyValued 

<dsig:Modulus>g0yM4ccyzA-=</dsig:Modulus> 
< ds ig : Exponent > AQABAA= = < / ds ig : Exponent > 
< / ds ig : RSAKeyValue > 
< /dsig : Key Valued 
< /dsig : Keylnf od 
</dsig:Signature> 
</r:issuer> 
</r : licensed 

Looking closely at the License above, we observe that it has the same two high-level parts as the end user 
License: an r: grant and an r: issuer, as shown in the following skeletal License outline. 

<r: license . . . d 
<r : grant > 
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<r:forAll varName= n AcmeMusicClubMember n > . . . </r:forAll> 
<r:keyHolder licensePartld^Xin" > . . . </r :keyHolder> 
<r:issue/> 
<r: grant > 

<r : principal varRef= "AcmeMusicClubMember n / > 
<mx:play/> 

<mx:diReference>. . . </mx: dlRef erence) 
<r:validitylnterval> . . . </r : validitylnterval> 
</r : grant > 

<sx:feePerUse> . . . </sx: f eePerUse) 
</r : grant > 
<r : issuer > 

<dsig : Signature> < /dsig : Signature > 

</r : issuer > 
</r:license> 

In this case, the r : issuer contains Alice's signature over the License. The r : grant has five parts: 

a) The r:forAli defines the Variable which will enable Alice to issue one License that Xin can use to 
distribute Licenses to several different end users. 

b) The r :keyHolder identifies that Xin is being granted rights. 

c) The r : issue identifies the right that Xin is being granted. 

d) The r: grant indicates that Xin is allowed to include a grant in Licenses he issues. 

e) The sx : f eePerUse identifies the account to which and amount that Xin must pay each time he issues a 
License having the r : grant. (This is how Alice indicates that each time Xin issues a License having an 
r : grant pursuant to her License, Xin must pay her $1 .) 

Of these five parts of the outer r : grant, the inner r : grant deserves closer inspection. It has four parts. 

The last three of these four parts (of the inner r : grant) are the same as the last three parts of the r : grant 
in the end user License. This is the way that Alice indicates to Xin that the end user r: grant elements he 
includes in the Licenses he issues pursuant to her License must have the exact Right, play, for an exact 
Resource (her Digital Item with identification urn: grid :al-abcde-l234567890-f) under an exact 
Condition (that playing occurs during 2003). 

The first of these four parts (of the inner r: grant) has an r:varRef, which is a reference to a Variable 
("AcmeMusicClubMember") that Xin is to resolve when he includes the r: grant in a License he issues. To 
determine what values this Variable may take on, Xin finds an r:forAii element with a corresponding 
r : varName. 

Looking at the r:forAii element that declares "AcmeMusicClubMember", we notice the presence of an 
npropertyPossessor pattern that has two parts: an sx:propertyUri and an 
r : trustedRootissuers set to Acme, as shown in the following skeletal outline. 

<r : f orAll varName= "AcmeMusicClubMember" > 
<r : propertyPossessor> 

<sx : propertyUri def inition= "urn : acme rmusicClubMember " / > 
<r: trustedRootissuers) . . . </r : trustedRootIssuers> 
< /r : propertyPossessor> 
</r:forAll> 

This r :f orAii element signifies that the valid values for the "AcmeMusicClubMember" Variable are all those 
r: Principal elements for which, in the simplest case, another License exists in which the trusted issuer 
grants that r : Principal the Right to possess the identified property (of club membership). 



98 



© ISO/IEC 2003 — All rights reserved 



SO/IEC FDIS 21 000-5: 2003(E) 



Because John is requesting a License from Xin, Xin will want to determine if John is a valid value for the 
"AcmeMusicClubMember" Variable. Therefore, before Xin issues a License to John, Xin must find a License 
issued by Acme that grants John the Right to possess the property urn : acme : musicClubMember. This 
License might look as follows: 

<?xml version= " 1 . 0 " encodings n UTF - 8 " ? > 
<r: license 

xmlns :r- "urn: mpeg: mpeg21 : 2003 : 01-REL-R-NS" 
xmlns : sx="urn rmpeg :mpeg21 : 2003 : 01-REL-SX-NS" 
xmlns : mx= " urn : mpe g : mpe g2 1:2003:01- REL -MX-NS" 
xmlns : dsig="http : //www. w3 . org/2000/09/xmldsig# " 
xmlns :xsi="http: //www.w3 . org/ 2 00 1/ XML Schema- instance" 
xsi : schemaLocat ion= " urn : mpeg : mpeg2 1 : 2003 : 01-REL-MX-NS rel-mx.xsd" > 
<r: grant > 

<r :keyHolder licensePartId=" John" > 
<r :info> 

<dsig : KeyValue> 

<dsig : RSAKeyValue> 

< ds ig : Modulus >K t dToQQy z A= = < / ds ig : Modulus > 
<dsig : Exponent >AQABAA«</dsig : Exponent > 
</dsig:RSAKeyValue> 
< / dsig : KeyValue> 
</r:info> 
< /r : keyHolder > 
<r :possessProperty/> 

< sx : propertyUri def ini t ion= "urn : acme : musicClubMember" / > 
</r: grant > 

<!--The license is issued and signed by Acme.~-> 
<r : issuer > 

<dsig : Signature > 

<dsig : Signedlnf o> 

<dsig : Canonical! zationMethod 

Algorithm="http://www,w3.org/TR/2001/REC-xml-cl4n-20010315"/> 
<dsig : SignatureMethod 

Algorithm^ "ht tp : / /www . w3 . org/ 2000/ 09 /xmldsig#r sa- shal " / > 
<dsig : Reference) 

< dsig: Transforms > 

<dsig: Transform Algorithm= 

"urn : mpeg rmpeg 21 : 2003 : 01-REL-R-NS : licenseTransf orm" / > 
< /dsig : Transforms) 
<dsig : Diges tMethod 

Algorithm= "http : / /www . w3 . org/ 2000/ 09 /xroldsig#shal " / > 
<dsig:DigestValue>Jk9QbKOQCo941tTExbjl/Q==</dsig:DigestValue> 
< /dsig : Reference) 
< /dsig : Signedlnf o> 

<dsig:SignatureValue>ABCqOhh5QQ«</dsig:SignatureValue> 
<dsig:KeyInfo> 

<dsig : Key Value > 

<dsig : RSAKeyValue> 

<dsig : Modulus >aaaM4ccyzA== < /dsig : Modulus > 
<dsig: Exponent >AQABAA==< /dsig: Exponent > 
< /dsig : RSAKey Value > 
< / ds i g : Key Value > 
</dsig:KeyInf o> 
< /dsig : Signature> 
</r:issuer> 
</r:license> 
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As illustrated in the following skeletal License outline below, the above License has an r : grant of three parts 
(that says John has the Right to possess the property urn : acme : rausicClubMember) and an r: issuer 
that contains the signature of Acme. 

<r: license . . • > 
<r: grant > 

<r : keyHolder licensePart Id= n John" > < /r : keyHolder > 

<r : possessProperty/ > 

<sx : propertyUri def inition= "urn : acme : musicClubMember" /> 
< /r: grant > 

<!--The license is issued and signed by Acme.--> 
<r:issuer> 

<dsig:Signature> . . . </dsig: Signature > 
</r:issuer> 
</r : license) 

If Xin has these two Licenses (the one from Acme plus the one from Alice) and pays $1 according to the 
License from Alice, Xin can issue John the simple end user License shown in D.2. 
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Annex E 

(informative) 



Desiqn philosophy concerning extensions and profiles of this part of 

ISO/IEC 21000 



E.1 General 

This Dart of ISO/IEC 21000 is careful to avoid a one-size-fits-all solution. It is structured in three parts: the 
core the standard extension, and the multimedia extension. The core provides the extensible framework by 
which Rights Expressions can be constructed given the proper extensions. The standard extension provides 
rnumbfr of general-purpose XML Schema elements, XML Schema types, and QNames that provide 
terminology necessary to construct many Rights Expressions across a wide spectrunr i of domains, indudmg 
the multimedia domain. The multimedia extension prov.des a number of XML Schema ^ents X^L 
Schema types that provide terminology necessary to construct many Rights Expressions in the multimedia 
domain. 

It is expected that others will construct additional extensions for their domains or for applications built on top of 
a particular domain. It is possible to construct extensions in such a way as to make them transparent except 
at those points in a distribution chain where they provide added functionality The content of the extension 
should be dictated by the requirements of the domain or application, but it should be constructed in such a 
way as to enable interoperability where the requirements intersect with those of other domains. It is ; also . kkriy 
to be advantageous to follow best practices documents that are developed over time To facilitate industry 
development of such a document, E.4 lists some extensibility points of this part of ISO/IEC 21000. 

This part of ISO/IEC 21000 can also be profiled. Profiles might be created for a number of reasons For 
instance, industry participants or groups of participants might work together to specify a profile that re fleets the 
functionality of the Users (devices, servers, applications, etc.) in their domain or environment Profiles m ght 
also be created that are applicable across many domain verticals based on device ^ctoonalrty °' ^P'^ t,0 n " 
requirements. For instance, a profile removing modification Rights nmght reflect the functionality of 
consumption-only devices that are not capable of modification. The lack of connectivrty in a class of 
unconnected devices might be reflected in a profile removing revocation features. 

As particular patterns are noticed in industry-developed profiles, ISO/IEC 21000-5 might be > amended I to 
include a handful of profiles that represent these patterns in order to encourage convergence to this handful of 
profiles, where possible, as a means of broadening the reach of interoperability. 



E.2 Definition of extension 

An Extension is a set of new XML Schema elements, XML Schema types, QNames and/or URIs usable 
within Riqhts Expressions. Some of these new XML Schema elements or XML Schema types might be 
derived from existing elements or types already defined in this part of ISO/IEC 21000 or in other extensions. 



E.3 Definition of profile 

A Profile is a set of rules that Rights Expressions meet in order to be considered compliant with that profile. 
These rules can take a number of forms. For instance, some rules might restrict specific XML Schema 
elemlnls XML Schema types, QNames, and/or URIs (from this part of ISO/IEC 21000 itself or any of rts 
extensions) and/or entire classes of any of these items. Other rules might mandate in much more detail the 
structure of complete Rights Expressions or parts thereof. 
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E.4 Extensibility points 

New XML Schema elements can be made to substitute the following. 

r : anXmlPatternAbs tract 
r: condition 

r : conditionPatternAbs tract 
r : dcConstraint 
r : licensePart 
r : principal 

r : principalPat t ernAbs tract 
r : propertyAbstract 
r : resource 

r : re sourcePatt ernAbs tract 
r : right 

r : r ight Pa t t ernAbs tract 
r : serviceDescription 
r: trustRoot 
sx : name 

New XML Schema types can be derived from the following. 

r: AnXmlPatternAbs tract 
r: Condition 

r : ConditionPatternAbs tract 
r : DcConstraint 
r : LicensePart 
r : Principal 

r : PrincipalPatternAbstract 
r : PropertyAbstract 
r: Resource 

r : ResourcePatt ernAbs tract 
r: Right 

r : Right Pat t ernAbs tract 
r : ServiceDescription 
r : TrustRoot 
sx : Name 

sx : Statef ulCondition 

New XML Schema elements can be made to place inside the following. 

r : Datum 

r : DigitalResource 

r : ExerciseMechanism 

r : License/r : otherlnf o 

r : RevocationMechanism 

sx : Account Payable 

sx: StateRef erenceValuePattern 

mx: IsMarked 

mx : Mark 

mx: set 

New QNames can be defined to place in the following. 

sx : Prof ileCompliance 
sx : Rate/ @sx: currency 

sx : Territory/ sx : location/ sx : country 
sx : Territory /sx : location/ sx : region 
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New URIs can be defined to place in the following 

r : AnXmlExpres sion/ @r : lang 
sx : PropertyUri/@sx : definition 
sx : RightUri/ @ sx : definition 
mx : set/@mx : definition 
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Annex F 

(informative) 



Extension mechanisms for introducing new rights 



F.1 General 

This Annex illustrates how a new Right can be introduced into Rights Expressions using several extension 
mechanisms provided in this part of ISO/IEC 21000. The illustrative Right is "copy" as defined by a 
hypothetical institution Acme as "make a single bit-for-bit version of a Digital Resource". This Right can be 
introduced into Rights Expressions using any one of the following four extension mechanisms: 

— Use existing r : Right and r : Condition elements. 

— Use sx : right Uri. 

— Use type extension (xsi : type). 

— Use element extension (xsd : subs t itut ionGroup) . 



F.2Use existing rights and conditions 

In many cases, a new Right can be introduced implicitly by using existing (or extended) Conditions to 
specialize (constrain or contextualize) existing Rights. 

According to the semantics of Acme's "copy," an exercise of this Right on a Digital Resource results in 
generating a new Digital Resource and maintaining the original unchanged. This is a specialization of the 
existing Right identified by rax: adapt. What is special about Acme's "copy" is a constraint about the 
comparison between the new and original Resources (they must have the same number of bits and match 
"bit-for-bit"). This implies that a list of resource attributes related to the bit-to-bit equivalence to the original 
Resource must be preserved for the new Resource. Thus, Acme's "copy" Right can be introduced as a 
specialization of the Right identified by mx: adapt using mx:prohibitedAttributeChanges for the list of 
resource attributes to be preserved. 

Now the issue is how to identify this resource attribute list within mx: prohibit edAttributeChanges. If 
Acme has the list specified, say at some URI urn: acme :copy-preservedAttributes, then Acme's 
"copy" Right can be introduced as a specialization of the Right identified by mx: adapt using this list, as 
shown in the following r : grant : 

<r: grant > 

<r :keyHolder> 

< /r : keyHolder > 

<mx: adapt /> 

<mx : diRef erence> 

<inx:identif ier>someResourceUri< /mx: identifier > 
< /mx : diRef erence > 
<mx:prohibitedAttributeChanges> 

<mx : set def inition= "urn : acme : copy-preservedAt tributes " / > 
< /mx : prohibit edAt tribut eChanges > 
</r : grant > 
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The list can also be specified using some hypothetically existing attributes from ISO/IEC 21000-6. For 
instance, Acme can consider two hypothetical attributes from ISO/IEC 21000-6, numberOfBits and 
bitSequence, as the ones that must be preserved. Assume that these two attributes have been defined in the 
Rights Data Dictionary with Term IDs as 2346 and 2347 and that they can be identified with the respective 
URIs: urn:mpeg:mpeg21:2003:01-RDD-NS:2346 (numberOfBits) and urn :mpeg:mpeg21 : 2003 : 01- 
rdd-ns : 2347 (bitSequence). 

Then, Acme's "copy" Right can be introduced as a specialization of the Right identified by mx: adapt using 
mx: prohibitedAttributeChanges as shown in the following r : grant: 

<r : grant > 

<r :keyHolder> 

< /r : keyHolder> 

<mx: adapt /> 

<mx: diRef erence> 

<mx : identif ier> someResourceUrK /mx : identif ier> 

< /mx : diRef erence) 

<mx : prohibitedAttributeChanges > 

<set definitions "urn : mpeg : mpeg2 1 : 2003 :01-RDD-NS: 2346" /> 
<set definition="urn:mpeg:mpeg21: 2003 :01-RDD-NS: 2347 "/> 

< /mx : prohibitedAttributeChanges > 
</r: grant > 



F.3Use rightUri 

The Standard Extension Namespace contains a type called sx: Right Uri. An sx: RightUri identifies a 
Right using a URI rather than an XML Schema element or type. The semantics of the Right being identified 
by an sx: RightUri is determined by the URI value of its sx: definition attribute. 

Using this mechanism, Acme's Right "copy" can be introduced as in the following r: grant (note that the URI 
value "urn : acme : copy" is used only for illustration): 

<r: grant > 

<r : keyHolder > 

< / r : keyHo lder > 

< sx : rightUri def init ion= " urn : acme : copy" / > 
<mx : diRef erence> 

<mx: identif ier>someResourceUri</mx: identif ier> 

< /mx : diRef erence > 
</r : grant > 

If Acme's "copy" is mapped into the Rights Data Dictionary (according to the mapping process defined in 
ISO/IEC 21000-6), the corresponding Term ID, say urn:mpeg:mpeg2l:2003:01-RDD-NS:2348, can then 
be specified as the URI value of the r : definition attribute as shown below: 

<r: grant > 

<r : keyHolder> 

< /r: key Ho lder > 

<sx : rightUri def init ion= "urn : mpeg : mpeg21 : 2003 : 01 -RDD-NS : 2348 " / > 
<mx : diRef erence> 

<mx : identif ier> someResourceUrK /mx : ident if ier> 
< /mx: diRef erence> 
</r : grant > 
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F.4Use type extension 

The W3C XML Schema mechanism of deriving types by extension using the attribute xsi:type is another 
way to add new Rights (and other building blocks) into Rights Expressions. The semantics of a new Right 
introduced in this manner is determined by the extension type specified. 

Assume that Acme's Right "copy" has already had an XML Schema type definition in some Namespace called 
acme that extends the XML Schema type r : Right, as follows: 

<xsd: complexType name = "Copy" > 

<xsd : complexCon t ent > 

<xsd: extension base=*r: Right "/> 

< /xsd : complexCon tent > 
< /xsd : complexType > 

Then, Acme's Right -'copy" can be introduced as in the following r : grant: 

<r: grant > 

<r : key Holder > 

< /r : keyHolder > 

<r: right xsi : type =" acme : Copy" /> 
<mx : diRef erence) 

<mx: identifier >someResourceUri</mx: ident if ier> 
< /mx: diRef erence) 
< /r: grant > 

However, this mechanism only presents the generic element r: right (though with a specific, new type); it 
does not provide the flexibility to introduce new r : Right elements such as acme : copy. 



F.SUse element extension 

New Rights can be introduced as derivations of the type r: Right and substitutions of the element r: right, 
via a W3C XML Schema extension mechanism, xsd:substitutionGroup, that is built into the W3C XML 
Schema. 

Acme's Right "copy" can be introduced using this mechanism within a Namespace acme, as follows: 

<xsd:element name= n copy w type=" acme: Copy" substitutionGroup="r: right" /> 

Then this r: Right element acme: copy can be used in an r: grant like the following to grant some 
Principal the Right to "copy" a Digital Item: 

<r: grant > 

<r: keyHolder > 

</r : keyHolder > 
<acme: copy/> 
<mx : diRef erence) 

<mx: identif ier>someResourceUri</mx: ident if ier> 
< /mx : diRef erence > 
< /r: grant > 
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Annex G 

(informative) 



Example profile of this part of ISO/IEC 21000 



G.1 General 



This Annex provides an example profile of this part of ISO/IEC 21000. This example profile is intended to 
demonstrate how to describe a class of Rights Expressions in sufficient detail to provide both License creators 
and License processors the guidance they require to create and process Rights Expressions conforming to 
this particular profile. 

The remainder of this Annex describes the content of the example profile description and provides some 
examples to illustrate its expressiveness. 

Note that creating profiles of ISO/IEC 21000 might benefit from publishing these profiles at a central location, 
but this is out of the scope of this Annex. 



G.2 Profile elements 



In essence, this example profile supports Licenses with one or more r: grant elements, and each r: grant 
has an optional r: keyHolder Principal element, an mx:play Right element, an mx: diRef erence 
Resource element, and optional nvaliditylnterval, sxrexerciseLimit, or their conjunctive 
Condition element. 

Specifically, this example profile contains a restricted set of elements from the Core Namespace, Standard 
Extension Namespace, and Multimedia Extension Namespace. Table G.1 shows these profile elements and 
their restriction, if any, on their non-profiled counterparts. Any elements that are not shown in Table G.1 are 
not part of the example profile. 



Table G.1 — Elements In the example profile 



Profile element 


Child element 


Occurrence of child 
element 


Occurrence of child 
element when not profiled 


r : license 


r ; grant 


1.. unbounded 


0.. unbounded 


r: issuer 


1..1 


0..unbounded 


r : grant 


r : keyHolder 


0..1 




mx : play 


1..1 




mx : diRef erence 


1..1 


0..1 


r : condition 


0..1 




r : keyHolder 


r :info 


1..1 


0..1 


mx:play 








rax : diRef erence 


rax: identifier 


1./I 


0..1 


r : allConditions 


r: condition 


2..2 


0.. unbounded 


r : validitylnterval 


rmotBefore 


0..1 




r: not After 


0..1 





© ISO/IEC 2003 — All rights reserved 



107 



ISO/I EC FDIS 21000-5:2003( 



sx : exerciseLimit 


sx : count 


1..1 


0..1 


r : Issuer 


r : keyHolder 


0..1 





G.3 Profile schema 
G.3.1 General 

Sometimes it is useful to construct schemas that represent which Licenses are conformant to the profile. 
Doing so, however, is generally not critical and will depend on what is the easiest way to convey a profile to 
others. If an intermediary is to verify that Licenses comply with a profile before passing them to devices that 
cannot deal well with errors, such schemas would be useful to that intermediary. 

If one does chose to construct schemas for a profile, much confusion would be avoided if those schemas had 
the following two properties: 

— Any License that is not valid according to the schemas in Annex A is also not valid according to the profile 
schemas. 

— Any License that is valid according to the profile schemas is also valid according to the schemas in 
Annex A. 

It is expected that some Licenses that are valid according to the schemas in Annex A will not be valid 
according to the profile schemas. 

The following three schemas demonstrate how schemas could be constructed for the example profile. 
G.3.2 Example profile schema for the Core Namespace 

<?xml version-"!. 0° encoding="UTF-8"?> 

<xsd : schema targetName space - n urn unpeg :mpeg21 : 2003 : 01-REL-R-NS" 

xmlns : r = " urn : mpeg : mpeg2 1 : 2003 : 01-REL-R-NS" 

xmlns :dsig="http: //www. w3.org/2000/09/xmldsig#" 

xmlns :xsd="http:/ /www . w3 . org/ 2001 /XML Schema " 

xroln s:sx=" urn : mpeg : mpe g21:2003:01-REL-SX-NS" 

xmlns :mx="urn : mpeg :mpeg21 : 2003 : 01-REL-MX-NS" 

element FormDefault= "qualified" attributeFormDef ault= "unqualified" > 

<xsd: import namespace="http : //www.w3 . org/XML/1998/namespace" 
schemaLocation="http: //www. w3.org/2001 /xml. xsd"/ > 

<xsd: import namespace="http : //www. w3 . org/2000/09/xmldsig#" 
schemaLocation="http: //www. w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core- 
schema . xsd " / > 

<xsd: import name space = "urn : mpeg: mpeg21 : 2003 : 01-REL-SX-NS" schemaLocation="rel- 
sx-prof ile . xsd" / > 

<xsd: import namespace= "urn : mpeg : mpeg 2 1 : 2003 : 01-REL-MX-NS" schemaLocation="rel- 
mx-prof ile. xsd" /> 

<xsd: element name= " license " > 
<xsd : complexType> 
<xsd : sequence) 

<xsd: element ref ="r : grant " maxOccurs=" unbounded" /> 
<xsd:element ref ="r: issuer" /> 
< /xsd : sequence) 

<xsd: attribute ref ="sx: prof ileCompliance"/> 
< /xsd : complexType> 




108 



© ISO/IEC 2003 — All rights reserved 



O/IEC FDIS 21000-5:2003(E) 



< /xsd : element > 



<xsd: element name= " grant " > 
<xsd : complexType> 
<xsd : sequence> 

<xsd:element ref ="r ikeyHolder" minOccurs= w 0 n /> 

<xsd:element ref ="mx : play"/) 

<xsd : element ref = "mx : dlRef erence" / > 

<xsd: choice minOccurs="0") 

<xsd : element ref = M sx : exerciseLimit " / > 
<xsd : element ref ="r: validi tylnt erval" / > 
<xsd : element name= " allCondit Ions " > 
<xsd : complexType > 
<xsd; sequence > 

<xsd : element ref ="sx: exerciseLimit " / > 
<xs d : element ref = " r : validitylnterval " / > 
< /xsd : sequence > 
< /xsd : complexType > 
< /xsd : element > 
< /xsd: choice > 
< /xsd : sequence > 
< /xsd : complexType > 
< /xsd : element > 



<xsd: element name="keyHolder"> 
<xsd : complexType> 
<xsd : sequence > 

<xsd:element name="info" type- "dsig: Key Inf oType"/) 
< /xsd : sequence > 
< /xsd : complexType > 
< /xsd : element > 



<xsd : element name- " validitylnterval " > 
< xsd : complexType > 
<xsd : sequence) 

<xsd:element name=" not Before" type="xsd: dateTime" minOccurs="0"/) 
<xsd:element name=" not After" type= "xsd : dateTime " minOccurs="0"/> 
</xsd: sequence) 
< /xsd : complexType) 
< /xsd : element > 



<xsd: element name= " issuer" > 
<xsd : complexType) 
<xsd: sequence) 

<xsd: element ref ="r ikeyHolder" minOccurs="0"/) 
< /xsd : sequence ) 
< /xsd : complexType) 
< /xsd : element) 

< /xsd r schema) 



G.3.3 Example profile schema for the Standard Extension Namespace 

<?xml version="1.0" encoding="UTF-8"?> 

<xsd: schema t argetNamespace= " urn : rapeg : mpeg2 1 : 2003 : 01-REL-SX-NS" 
xmlns : sx="urn :mpeg :mpeg21 : 2003 : 01-REL-SX-NS" 
xmlns : xs d= " ht t p : / /www . w3 . org / 2 0 0 1 /XML Schema " 

elementFormDef ault= "qualified" attributeFormDef ault=" unqualified " > 
<xsd : element name= " exerciseLimit " > 
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<xsd : complexType > 
<xsd : sequence > 

<xsd:element name- "count" type= "xsd: integer" /> 
</xsd: sequence> 
< /xsd : complexType> 
< /xsd : element > 

<xsd : attribute name= "prof ileCompliance " > 

<xsd: simpleType> 

<xsd: list itemType="xsd:QName"/> 

</xsd:simpleType> 
< /xsd : attribute> 

< /xsd : schema > 

G.3.4 Example profile schema for the Multimedia Extension Namespace 

<?xml version= "1.0" encoding="UTF-8"?> 

<xsd : schema t ar get Name space =" urn :mpeg :mpeg21 : 2003 : 01-REL-MX-NS" 
xmlns : mx= " urn : mpeg : mpeg 2 1:2003:01- REL -MX - NS " 
xmlns : xsd= " ht t p : / /www • w3 . org / 2 0 0 1 /XML Schema " 

elementFormDefault= "qualified" attributeFormDef ault= "unqualified" > 

<xsd: element name="play"/> 

<xsd: element narae="diRef erence" > 
<xsd : complexType > 
<xsd: sequence > 

<xsd: element name= "identifier" type="xsd: anyURI"/> 
< /xsd : sequence > 
< /xsd : complexType > 
< /xsd : element > 

</xsd:schema> 



G.4 Profile signalling 

Sometimes it is useful to signal on each License the profile or profiles to which it is compliant. By looking for 
these hints, processors can avoid spending resources processing Licenses that they are not likely to support. 

This signalling is accomplished with the sx: prof ileCompliance attribute. Each profile defines the 
Qualified Name that should be used to signal that profile. The example profile defined here uses the value 
acme : example. 



G.5 Profile expressiveness 
G.5.1 General 

With this profile, one has the ability to issue Licenses for everyone or for any individual key holder to play a 
song during a specific window of time and to limit the number of plays. 

G.5.2 Everyone can play a song for the year of 2004 

<?xml version="1.0" encoding="UTF-8" ?> 

<r : license xmlns : acme =" urn : acme " sx : prof ileCompliance= " acme : example " 
xmlns :r= "urn: mpeg: mpeg21 : 2003 : 01 -REL -R-NS" 
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xmlns : sx= "urn : mpeg : mpeg2 1 : 2003 : 01-REL- SX-NS" 
xmlns : mx= w urn: mpeg :mpeg21 : 2003 : 01-REL-MX-NS" 
xmlns :dsig="http: //www. w3.org/2000/09/xmldsig#" 
xmlns :xsi="http: //www.w3 . org/2001/XMLSchema-instance" 

xsi: schemaLocation= "urn: mpeg :mpeg21: 2003: 01-REL-R-NS rel-r-prof ile .xsd" > 
<r : grant > 

<mx:play/> 

<mx : diRef erence> 

<mx : ident if ier >ht tp : / /www . onllnemuslc . com/mySong . mp3< /mx : identifier > 
< /mx : diRef erence> 
<r : validitylnterval> 

<r:notBefore>2004-01-01T00:00:00</r:notBefore> 
<r:notAfter>2005-01-01T00:00:00</r:notAfter> 
< /r : validity Interval > 
< /r: grant > 
<r : issuer > 

<r : keyHolder > 
<r:info> 

<dsig : KeyValue> 

<dsig : RSAKeyValue> 

<dsig : Modulus >Fa7wo6NYf m= - < / dsig : Modulus > 
<dsig : Exponent >AQABAA-=< /dsig : Exponent > 
< /dsig : RS AKey Value > 
< /dsig : KeyValue> 
</r:info> 
< /r : keyHolder > 
< /r: issuer > 
</r:license> 

G.5.3 A key holder can play a song three times within the year of 2004 

<?xml version="l .0" encoding="UTF-8" ?> 

<r : license xmlns : acme- "urn : acme" sx : prof ileCompliance- "acme : example" 

xmlns :r="urn:mpeg:mpeg21: 2003: 01-REL-R-NS" 

xmlns : sx= "urn : mpeg :mpeg21 : 2003 : 01-REL-SX-NS" 

xmlns :mx=" urn : mpeg: mpeg21 : 2003 : 01-REL-MX-NS" 

xmlns : dsig= " ht tp : / /www . w3 . org/ 2000/09 /xmldsig# " 

xmlns : xsi= "ht tp : / /www . w3 . org/ 200 1 /XMLSchema- instance " 

xsi : schemaLocation= "urn : mpeg :mpeg21 : 2003 : 01-REL-R-NS rel-r-prof ile .xsd" > 
<r: grant > 

<r : keyHolder > 
<r:info> 

<dsig : KeyValue> 

<dsig : RSAKeyValue> 

<dsig:Modulus>g8NRYMG307==</dsig:Modulus> 
< dsig: Exponent >AQABAA«< /dsig: Exponent > 
< /dsig : RSAKeyValue> 
< / ds ig : Key Value > 
</r:info> 
< /r : keyHolder > 
<mx:play/> 
<mx : diRef erence> 

<mx : ident if ier >http : //www. onlinemusic .com/mySong .mp3< /mx: ident if ier > 
< /mx : diRef erence > 
<r : allConditions> 

< sx : exerciseLimit > 

< sx : count > 3 < / sx : count > 
< /sx : exerciseLimit > 

<r: validity Interval > 

< r : not Before >2004-01-0 1T0 0 : 0 0 : 00 < /r : no tBef ore> 
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<r:notAfter>2005-01-01T00:00:00</r:notAfter> 
< /r : validity Interval > 
< /r : allConditions > 
</r : grant > 
<r:issuer> 

<r:keyHolder> 
<r:info> 

< dsig : KeyValue > 

<dsig : RSAKeyValue> 

<dsig:Modulus>Fa7wo6NYfm==</dsig:Modulus> 
<dsig : Exponent >AQABAA==< /dsig : Exponent > 
< /dsig : RSAKeyValue> 
< /dsig : KeyValue > 
</r:info> 
< /r : keyHolder > 
</r:issuer> 
</r:license> 
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Annex H 

(informative) 



Relationship between ISO/I EC 21000-6 and this part of ISO/IEC 21000 



There are a number of specific mechanisms by which Terms defined within ISO/IEC 21000-5 can be 
represented in Rights Expressions. One is described in this Annex, and others are illustrated by the 
combination of Annex F of this standard and D.2 of ISO/IEC 21 000-6. 

This part of ISO/IEC 21000 defines a set of XML Schema complex types that, in the XML Schema sense, 
derive from the conceptually abstract type r: Right. Some of these types reside in the Multimedia Extension 
Namespace. For convenience, in this Annex, these types are called Multimedia Rights. 

Each activity has a context that can be related to particular ActType(s) within the ontology given by ISO/IEC 
21000-6. An activity is said to be within the scope of a particular Multimedia Right if the activity's context is a 
specialization of the ActType corresponding to the Multimedia Right. 
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Annex I 

(informative) 

Relationship between ISO/IEC 21000-2 and this part of ISO/IEC 21000 



An mx:DiReference or rax: DiltemRef erence can be used to identify a Digital Item (with or without its 
sub-Digital Items, respectively). An mx:DiRef erence can also be used to identify a Container, Descriptor, 
Component, or Fragment. When variables are used with mxrDiRef erence, an mx:DiCriteria or 
mx:DiPartOf can be used to constrain which Containers, Descriptors, Digital Items, Components, or 
Fragments a Rights Expression applies to based on information about their metadata or structure, respectively, 
provided in their Digital Item Declarations. 

Rights Expressions can be included in Digital Items (including in their Digital Item Declarations). The example 
below shows a Rights Expression included in the Digital Item it pertains to. It is important to note, however, 
that such relationship is not required: a Rights Expression included in one Digital Item can pertain to a 
different Digital Item. Each Rights Expression indicates which Digital Items, if any, it pertains to. Other parts 
of ISO/IEC 21000 might elaborate on some mechanisms for locating or acquiring Rights Expressions pertinent 
to a given Digital Item or for locating or acquiring Digital Items pertinent to a given Rights Expression. This 
part of ISO/IEC 21000 does not normatively specify or suggest any such mechanisms. 

<?xml version="1.0" encodings "UTF- 8 " ?> 
<didl:DIDL 

xmlns :didl= "urn : mpeg :mpeg21 : 2002: 01-DIDL-NS" 

xralns : dii= "urn : mpeg :mpeg21 : 2002 : 01-DII-NS" 

xmlns : xsi= " ht tp : / /www . w3 • org/ 20 0 1 /XMLS enema- instance " 

xsi : schemaLocat ion= " urn : mpeg : rapeg2 1 : 2002 : 01-DIDL-NS did.xsd 

urn :mpeg :mpeg21 : 2002 : 01-DII-NS dii.xsd 
urn : mpeg : mpeg 2 1 : 2003 : 01-REL-MX-NS rel-mx.xsd" > 

<didl:Item> 

<dldl : Descriptor> 

<didl : Statement mimeType=" text/xml" > 

<dii : Identif ier>urn : grid : al-abcde-2468013579-f </dii : Identif ier> 
< /didl : Statement > 
< /didl : Descriptor > 
<didl : Descriptor> 

<didl: Statement mimeType=" text/xml "> 
<r: license 

xmlns :r= "urn: mpeg :mpeg21: 2003: 01-REL-R-NS" 
xmlns :sx= "urn: mpeg : mpeg21 : 2003 : 01-REL-SX-NS" 
xmlns :mx=" urn : mpeg : mpeg 2 1:2003:01- REL-MX- NS " 
xmlns : dsig= "http : / /www . w3 . org/2000/09/xmldsig# " > 
<r : grantGroup> 
<r : keyHolder > 
<r:info> 

<dsig : KeyValue> 

<dsig : RSAKeyValue> 

<dsig : Modulus >QToKtdQyzA== < /dsig : Modulus > 
<dsig: Exponent >AQABAA==</dsig: Exponent > 
< / ds i g : RSAKey Value > 
< /dsig : KeyValue> 
</r:info> 
< /r : keyHolder > 
<r :validitylnterval> 

<r :notBefore>2003-01-01T00: 00 : 00</r :notBef ore> 
<r:notAfter>2004-01-01T00:00:00</r:notAfter> 
< /r : validitylnterval> 
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<r : grant > 

<mx:play/> 

<mx : diRef erence> 

<mx:identifier>urn:grid:al-abcde-2468013579- 

f < /rax : identifier > 

</mx: diRef er ence > 
</r : grant > 
<r : grant > 

<mx: print /> 

<mx : diRef erence> 

<mx:identifier>urn:grid:al-abcde-9630741852- 

f < /rax : ident if ier> 

< /mx : diRef erence) 
</r : grant > 
< /r : grantGroup> 
<r: issuer > 

<r :keyHolder> 
<r:info> 

<dsig : Key Value > 

<dsig : RSAKeyValue> 

<dsig : Modulus > j 9yzX09q9A==< /dsig : Modulus > 
<dsig : Exponent >AQABAA«</dsig : Exponent > 
< /dsig : RSAKey Value > 
</dsig:KeyValue> 
</r:info> 
< / r : keyHolder > 
< /r: issuer > 
</r : license> 
< / didl : St at ement > 
< /didl : Descriptor > 

< didl : Component > 

<didl : Descriptor > 

<didl: Statement mimeType= " text /xml" > 

<dii:Identifier>urn:grid:al-abcde-9873216540-f</dii:Identifier> 

< /didl : Statement > 
< /didl : Descriptor> 

<didl: Resource mimeType=" video /mpeg" ref ="acme_goes__bonkers .mpg /> 
< /didl : Component > 

< didl : Component > 

<didl : Descriptor > 

<didl : Statement mimeType=" text /xml" > 

<dii:Identifier>urn:grid:al-abcde-9630741852-f</dii: Identified 

< /didl : Statement > 
< /didl : Descriptor > 

<didl: Resource mimeType=" text /html " ref ="cover_notes .html"/> 
< /didl : Component > 
</didl:Item> 
</didl:DIDL> 
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Annex J 

(informative) 

Example revocation mechanism 



J.1 General 

This Annex describes an example revocation mechanism. This example revocation mechanism is intended to 
demonstrate the considerations pertinent to designing and using revocation mechanisms to construct working 
revocation functionality. The remainder of this Annex gives a walk-through of a revocation scenario. 



J.2 Designing a revocation mechanism 

Acme wants to design a revocation mechanism that simply publishes revocation data at a particular URL, 
http://www.acme.org/revocationData/XJDf.xml, where XXX changes depending on the revocable in 
question. Acme wants the revocation mechanism to allow the issuer of a License to revoke his (the issuer's) 
revocable for the License and freely delegate that ability to others. The revocation data is to be updated 
hourly to be good for five hours, assuming no revocation request has been received. 

To do this, Acme needs to create a way to signal this revocation mechanism in a License. He can accomplish 
this using XML Schema: 

<xsd: element name-'revocationUrl" > 

< xsd : complexType > 

<xsd: attribute name= "value" type= "xsd: string" use= "required" /> 

< /xsd : complexType > 
< /xsd : element > 

Acme also needs to define how to check for freshness. The check is made by visiting the particular URL and 
inspecting the format of the document at that URL. This format is given using XML Schema: 

<xsd: element name="revocationData" > 
<xsd : complexType > 
<xsd ; sequence) 

<xsd:element ref ="r: revocable" /> 

<xsd : element name= " f reshThrough" type= "xsd : dateTime" / > 
<xsd: element ref ="dsig: Signature "/> 
</xsd: sequence > 
</xsd: complexType > 
< /xsd : element > 

Acme also needs to define how an issuer informs the revocation mechanism that the issuer wants to revoke 
the revocable for his License. In this case, a document conforming to the following XML Schema is to be e- 
mailed to revocationRequest ©acme . org: 

<xsd : element name= " revocationRequest " > 
<xsd : complexType > 
<xsd : sequence) 

<xsd : element ref = "r : revocable " / > 
<xsd : element ref = "r : licenseGroup " / > 
<xsd: element ref ="dsig: Signature" /> 
< /xsd i sequence > 
< /xsd : complexType > 
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</xsd: element > 



J.3 Indicating a revocation mechanism and freshness Condition when issuinq a 
License * 

Alice hears about Acme's revocation mechanism, does an evaluation of the revocation mechanism and the 
stature of Acme, and decides to use Acme's revocation mechanism in her new License to John To do this 
she contacts Acme, agrees on a URL for her revocation data on Acme's site, and signals the corresponding 
revocation mechanism in her License. She also includes a revocation freshness Condition of three hours. 

<?xml version="1.0 w encoding="UTF-8" ?> 
<r: license 

xmlns : r= "urn : mpeg : mpeg2 1 : 2003 z 01-REL-R-NS" 
xmlns : mx= " urn : mpeg : mpeg2 1 : 2 0 0 3 : 0 1 - REL -MX- NS " 
xmlns : dsig= "http : //www . w3 . org/2000/09/xmlds±g# " 
xmlns : xs i= B ht tp : / /www • w3 . org/ 2 001 /XMLSchema- ins t ance " 
xmlns : acme= " urn : acme : REL -NS" 

xsi : schemaLocat ion= "urn : acme : REL -NS acme . xsd" > 
<r: grant > 

<r : keyHolder licensePart Id= " John n > 
<r:info> 

<dsig:KeyValue> 

<ds±g : RSAKey Value > 

<dsig: Modulus >JohM4ccyzA==< /dsig: Modulus) 
<dsig : Exponent >AQABAA== </ dsig s Exponent > 
< /dsig : RSAKeyValue> 
< /dsig : Key Value > 
</r:info) 
< /r : keyHolder > 
<mx:play/> 
<mx : diRef erence) 

<mx : ident if ier>urn : alice : photographs : superbowl25< /mx : ident if ier > 
< /mx : diRef erence > 
<r : revocat ionFreshness> 

<r : priorToStart >PT3H< /r : priorToStart > 
< /r : revocat ionFreshness > 
< /r: grant > 
<r:issuer> 

<dsig:Signature> 

<dsig : Signedlnf o> 

<dsig : CanonicalizationMethod 

Algorithm= n http: //www. w3.org/TR/2001/REC-xml-cl4n-20010315" /> 
<dsig: SignatureMethod 

Algorithm= "http: //www. w3.org/2000/09/xmldsig#rsa-shal"/> 
<dsig : Ref erence) 

<dsig : Transforms) 

< ds ig : Trans form Algor i thm= " urn : mpeg : mpeg2 1:2003:01- REL - R - 
NS : licenseTransf orm" / > 

07 10"/> <dsig: Transform Algorithm^ urn :uddi- org: schemaCentricC14N: 2002- 

< /dsig : Transforms > 

<dsig : DigestMethod 

Algorithm="http://www.w3.org/2000/09/xmldsig#shal"/> 

<dsig:DigestValue>Jk9QbKOQCo941tTExbjl/Q==</dsig:DigestValue> 
< /dsig : Ref erence) 

</dsig: Signedlnf o> 

<dsig : SignatureValue)DFgq0hh5QQ==</dsig : SignatureValue) 
<dsig:Key!nfo> 
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<dsig : KeyValue> 

<dsig : RSAKey Value > 

<dsig:Modulus)AliM4ccyzA==< /dsig: Modulus) 
<dsig : Exponent >AQABAA== < /dsig : Exponent > 
</dsig : RSAKey Value > 
< /dsig : KeyValue> 
< /dsig : Keylnf o> 
< /dsig : Signature > 
<r :details> 

<r:timeOf Issue)2003-02-01T00 : 00 : 00</r: timeOf Issue) 
< r : r e voc a t i onMechan i sm > 

<acme : revocationUrl value= "DFg" / > 
< /r : revocat ionMechanism> 
</r:details> 
</r:issuer> 
</r:license> 



J.4 Checking for freshness 

When John wants to see the photos at 2003-02-1 4T1 2:30:00, he visits 
ht tp : / /www . acme . org/revocat ionData/DFg . xml and retrieves the following revocation data: 

<?xml version= n 1.0 n encoding="UTF-8" ?> 
<acme : revocat ionDat a 

xmlns : r="urn :mpeg :mpeg21 : 2003 : 01-REL-R-NS" 
xmlns : dsig= "http : / /www . w3 . org/2000/09/xmldsig# " 

xmlns :xsi="http: //www. w3.org/2001/XMLSchema-instance" 
xmlns : acme = "urn : acme : REL-NS" 

xsi : schemaLocat ion= "urn : acme : REL-NS acme.xsd") 
<r : revocable) 

<dsig:SignatureValue>DFgqOhh5QQ==</dsig:SignatureValue> 
< /r : revocable) 

<acme:freshThrough>2003-02-14T17:00;00</acme:freshThrough> 
<dsig: Signature) 

<dsig:SignedInfo> 

<dsig:CanonicalizationMethod Algorithm=°http: //www. w3 .org/TR/2001/REC- 
xml-cl4n- 20010315 n /> 

<dsig:SignatureMethod Algorithm= "http: //www. w3 . org/ 2000/ 09 /xmldsig#rsa- 

shal"/> 

<dsig : Reference) 

<dsig : Transforms) 
<dsig : Transform 

Algorithm= "http: //www. w3 . org/ 2000/ 09/xmldsig#enveloped- signature " /) 
< /dsig : Transforms > 
<dsig : Diges tMethod 
Algorithm="http://www.w3.org/2000/09/xmldsig#shal"/> 

<dsig : Diges t Value >TJk9o9 4 ltQbKOQCExbjl/Q==< /dsig : DigestValue) 
< /dsig: Reference) 
< /dsig : Signedlnf o) 

<dsig : SignatureValue)u8EqOhh5QQ==</dsig : SignatureValue) 
<dsig : Keylnf o> 

<dsig:KeyValue) 

<dsig : RSAKeyValue) 

< ds ig : Modulus > RevM4 ccy zA= = < / ds ig : Modulus > 
<dsig : Exponent >AQABAA==< /dsig : Exponent) 
< /dsig : RSAKeyValue) 
< /dsig : Key Value) 
< /dsig : Keylnf o> 
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< /dsig : Signature> 
< /acme : revocat ionData> 

After verifying the Acme's signature, John knows that Acme guarantees no revocation is in effect until 2003- 
02-14X17:00:00. Because 2003-02-1 4T1 7:00:00 is greater than 2003-02-1 4T1 2:30:00 (the time of start) 
minus PT3H (the period in the revocation freshness Condition), John proceeds with viewing the photos. 



J.5 Delegating revoke Right 

Alice decides to let Bob manage the revocation of her revocable for John's License. To do this, she gives him 
the following License: 

<?xml version="1.0 n encodings "UTF- 8 ■ ?> 
<r: license 

xmlns :r= n urn: mpeg:mpeg21 : 2003 : 01-REL-R-NS" 
xmlns : mx= " urn : mpeg ; mpeg2 1 : 2003 : 01-REL-MX-NS" 
xmlns : dsig- ■ ht tp : / /www . w3 . org/ 20 00 / 0 9 /xmlds ig# " 
xmlns : xsi= " ht tp : / /www . w3 . org/ 2001 /XMLSchema- instance ■ 
xmln s : acme = " urn : acme : REL-NS" 

xsi: schemaLocat ions " urn: acme: REL-NS acme.xsd"> 
<r : grant > 

<r : delegationControl/ > 
<r:keyHolder licensePartId="Bob ,, > 
<r:info> 

< ds ig : Key Value > 

<dsig : RSAKeyValue> 

<dsig:Modulus>BobM4ccyzA«</dsig:Modulus> 
< ds i g : Exponent >AQABAA= = < / ds ig : Exponent > 
< /dsig : RSAKeyValue> 
< /dsig : Key Value > 
</r:info> 
</r : keyHolder > 
<r : revoke/ > 
<r : revocable > 

<dsig:SignatureValue>DFgqOhh5QQ==</dsig:SignatureValue> 
< /r : revocable> 
< /r: grant > 
<r:issuer> 

<dsig : Signature> 

<dsig: Signedlnf o> 

<dsig : Canonical! z at ionMethod 
Algorithm="bttp://www.w3.org/TR/2001/REC-xml-cl4n-20010315"/> 

<dsig : SignatureMethod 
Algoritnm= n http://www.w3.org/2000/09/xmldsig#rsa-shal"/> 
< ds i g : Re f er ence > 

<dsig : Transforms > 

< dsig : Transform Algorithm^ " urn : mpeg : mpeg2 1:2003:0 1-REL-R- 
NS : licenseTransf orm" / > 

<dsig: Transform Algor i thm= w urn :uddi- org : schemaCentricC14N: 2002- 

07-10"/> 

< /dsig : Transf orms> 
<dsig : Diges tMethod 
Algorithm= n http://www.w3.org/2000/09/xmldsig#shal"/> 

<dsig:DigestValue>o941Jk9QbKOQCtTExbjl/Q==</dsig:DigestValue> 
</dsig:Ref erence) 
< /dsig: Signedlnf o> 

<dsig: Signature Value >B2wqOhh5QQ==< /dsig : SignatureValue> 
<dsig : Keylnf o> 
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<dsig:KeyValue> 

< ds i g : RSAKey Value > 

<dsig:Modulus>AliM4ccyzA==</dsig:Modulus> 
< ds i g : Exponent >AQABAA= = < / ds i g : Exponen t > 
< /dsig : RSAKey Value > 
< /dsig : KeyValue> 
< /dsig : Keylnf o> 
< /dsig: Signature > 
<r : details > 

<r:timeOfIssue>2003-02-14T13:00:00</r:timeOfIssue> 
</r:details> 
< /r: issuer > 
</r:license> 



J.6 Requesting revocation 

At 2003-02-1 4T1 4:30:00, Bob decides to revoke Alice's revocable for John's License. To do this, he signs the 
following message (containing Alice's License to him) and e-mails it to Acme: 

<?xml version="l. 0" encoding="UTF-8" ?> 
<acme : revocat ionReques t 

xmlns : r = ■ urn : mpeg : mpe g 2 1:2003:01- REL -R-NS" 
xmlns :dsig= "http: //www. w3 . org/ 2000/0 9/xmldsig#" 
xmlns : xsi= " ht tp : / /www . w3 . org/ 2001 /XML Schema- instance B 
xmlns : acme= "urn : acme : REL-NS" 

xsi : schemaLocat ion= "urn : acme : REL-NS acme.xsd" > 
<r : revocable > 

<dsig : SignatureValue>DFgqOhh5QQ«< /dsig : Signature Value > 
< /r : revocable> 
<r : llcenseGroup> 

<r: license 

xmlns :r= "urn :mpeg :mpeg21 : 2003: 01-REL-R-NS" 
xmlns :mx= "urn : mpeg : mpeg 21 : 2003 : 01-REL-MX-NS" 
xmlns : dsig= "http : //www. w3 . org/2000/09/xmldsig# " 
xmlns : xsi= "http : / /www . w3 . org/200 1 /XML Schema- instance " 
xmlns : acme- " urn : acme : REL - NS " 

xsi : schemaLocation- "urn : acme : REL-NS acme . xsd" > 
<r: grant > 

<r : delegationControl/ > 
<r:keyHolder licensePartId="Bob" > 
<r:info> 

<dsig : KeyValue> 

< ds ig : RSAKey Value > 

<dsig:Modulus>BobM4ccyzA==</dsig:Modulus> 
<dsig : Exponent > AQABAA = -</ ds ig : Exponent > 
< /dsig : RSAKeyValue> 
< /dsig : Key Value > 
</r:info> 
</r:keyHolder> 
<r : revoke/ > 
< r : re vocable > 

<dsig:SignatureValue>DFgqOhh5QQ==:</dsig:SignatureValue> 
</r :revocable> 
< /r: grant > 
<r :issuer> 

<dsig : Signature> 

<dsig : Signedlnf o> 
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<dsig : Canonicalizat ionMethod 
Algor±thm=: n http://www.w3.org/TR/2001/REC-xnil-cl4n-20010315 n /> 

<dsig : SignatureMethod 
Algorithm= "http : / /www . w3 . org/ 2000 / 09 /xmldsig#rsa- shal " / > 

<dsig : Reference) 

<ds±g : Transforms) 

<dsig : Transform Algorithm= "urn :mpeg : mpeg21 : 2003 : 01 -REL-R- 

NS : licenseTransf orm" / > 

<dsig : Transform Algorithm= "urn : uddi- 
org : schemaCent ricCl 4N :2002-07-10"/> 

</dsig:Transf orms> 

<dsig : Diges tMethod 
Algor i thm= n ht tp : / / www • w3 . org/ 2000/09 /xmlds ig# shal " / > 

<dsig:DigestValue>o941Jk9QbKOQCtTExbjl/Q==</dsxg:DigestValue> 

< /dsig : Reference) 
</dsig:SignedInfo> 

<dsig : SignatureValue)B2wqOhh5QQ"< /dsig ; SignatureValue) 
<dsig:Key!nfo) 

<dsig:KeyValue> 

<dsig : RSAKeyValue> 

<dsig : Modulus >Al±M4ccyzA==< /dsig : Modulus) 
<dsig : Exponent >AQABAA==< /dsig : Exponent) 
< /dsig : RSAKey Value) 
</dsig:KeyValue> 
</dsig:KeyInfo) 
< /dsig : Signature) 
<r:details) 

<r:timeOf Issue)2003-02-14T13 : 00: 00</r : timeOf Issue) 
</r: details) 
</r : issuer) 
</r : license) 
< /r : licenseGroup) 
<dsig : Signature) 

<dsig : Signedlnf o) 

<dsig: Canonicallzat ionMethod Algorithm="http: //www. w3 .org/TR/ 2001 /REC- 

xml-cl4n-20010315"/> 

<dsig : SignatureMethod Algorithm- " ht tp : / /www . w3 . org/ 2 0 00 / 09 /xmldsig#rsa- 

shal n /) 

<dsig : Reference) 

< dsig: Transforms) 
<dsig : Transform 

Algorithm= w http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> 

< /dsig: Transforms) 

<dsig : DigestMethod 
Algor i thm= ■ ht t p : / / www . w3 . org/ 2 00 0 / 0 9 /xmlds ig# shal ■ / > 

<dsig:DigestValue)CExbTJk9o941tQbKOQjl/Q==</dsig:DigestValue> 

< /dsig : Reference) 
</dsig : Signedlnf o> 

<dsig : SignatureValue)h5Qu8EqOhQ==< /dsig : SignatureValue) 
<dsig:KeyInfo> 

< ds ig : Key Value > 

<dsig : RSAKeyValue) 

<dsig:Modulus)BobM4ccyzA==</dsig:Modulus) 
<dsig : Exponent )AQABAA= = < /dsig : Exponent > 
< /dsig : RSAKeyValue) 
< / ds ig : Key Value > 
</dsig:KeyInf o> 
< / ds i g : Signature ) 
< /acme : revocat ionRequest ) 
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When Acme receives this message, Acme wili wish to establish whether the revocation is permitted or not. To 
do this, Acme forms an authorization request with the following seven members: 

a) The r : Principal identifying Bob, 

b) The r : revoke element, 

c) The r : revocable given in Bob's revocation request above, 

d) A time interval of zero length for the present time, 2003-02-1 4T1 4:30:00, 

e) An authorization context including the time at which Alice issued the License to Bob and the authorization 
context for her Inclusion of the r : grant inside that License, 

f) A set of Licenses containing the Licenses inside the r ; licenseGroup in Bob's revocation request 
above, and 

g) A set of r : Grant elements with just the one member given below. 

<r: grant > 

<r : delegat ionControl/ > 
<r ; keyHolder licensePart Id= "Alice " > 
<r:info> 

< ds ig : KeyValue > 

<dsig:RSAKeyValue> 

< dsig ; Modulus >AliM4ccyzA== < /dsig : Modulus > 
<dsig:Exponent>AQABAA«</dsig:Exponent> 
< / ds ig : RSAKey Value > 
< /dsig : KeyValue> 
</r:info> 
< / r : keyHolder > 
<r: revoke/ > 
<r : revocable > 

<dsig:SignatureValue>DFgqOhh5QQ==</dsig:SignatureValue> 
< /r : revocable > 
</r: grant > 

If there is an authorization proof for the above authorization request (which there is, in this case), then Acme 
considers the requested revocation permitted and proceeds with the process of putting it into effect. If there is 
no authorization proof for the above authorization request, then Acme considers the requested revocation not 
permitted and does not put it into effect. 



J .7 Latency until revocation goes into effect 

Each revocation mechanism has a built in latency (possibly zero) between the time revocation is requested 
and the time it goes into effect. This latency is due to the fact that the revocation mechanism has to 
guarantee freshness for a certain duration (possibly zero) into the future. At 2003-02-1 4T1 4:00:00, Acme 
guaranteed freshness through 2003-02-1 4T1 9:00:00 according to its policy, which was approved by Alice. 
Thus, because Bob is requesting revocation at 2003-02-1 4T1 4:30:00, Acme will not update (at its next update 
cycle at 2003-02-1 4T1 5:00:00) the freshness for Alice's revocable for John's License. Instead, Acme will 
continue to only guarantee freshness through 2003-02-1 4T1 9:00:00. Even after 2003-02-1 4T1 9:00:00, Acme 
will only guarantee freshness through 2003-02-1 4T1 9:00:00. Therefore, we say the revocation goes into 
effect at 2003-02-14T19:00:00. 
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J.8 Latency until freshness duration passes 

Each r: Grant in a License has a built-in latency (possibly zero) between the time revocation goes into effect 
and the time the Conditions on the r : Grant cease to be Satisfied. In this case, this duration Alice used is 
PT3H (three hours), so John can still view the pictures starting all the way through 2003-02- 14T22:00:00, 
which is three hours after 2003-02-1 4T1 9:00:00, the time the revocation goes into effect. 
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